【最強の技術者集団】を謳う倍率200倍のアプリ会社に転職した。

転職は入ってみないとわからない

チョコレートの箱のようなもの👦🎁✨

 

転職後に初めて携わったプロジェクトが２名の技術者によるバックエンドで、DDDの思想を受けて作られたものであった。

ソースコードを見た

この会社に入って良かった。

「当たりを引いたな🎁✨」と確信。*1

 

他の既存のシステムを拡張するプロジェクトに参加した。

…ぐちゃぐちゃ🐱💦

 

属人化が強くプロジェクト参画メンバーによって品質が全然違っていた。。

少し知識を持っている分野では、なんじゃこりゃ？？

になってたり。アプリに特化している性質上で技術がものすごく偏っていた。*2

 

ガチャ！要素が強い

最強の集団に入ってすごい人達とお仕事できたら、いつの間にかワイくんも最強になれるのでは？

っていうのはいろいろ勘違いだった💦

ならこの世界で

君はどう生きるか*3

 

• *1 このプロジェクトは私の財産になっています。
• *2 会社の技術 = 私が所属している部署+知れるレベルのスコープです。
• *3 会社が言う最強っていうのは技術ではないと今は解釈しています。気持ちかな？挑戦的なひとが多いです！そもそもさ、よわよわな私が入れてる時点で技術的に最強ではないのだよね。すまんな。

 

最強であるには

 

最強の集団に入って凄いひと達と仕事すれば
いつの間にか自分も最強になれるのかな？👦✨
そう考えてました

PJ参画メンバー依存や入れ替わり
理想と現実はある
自分がテックリードになって
会社の底上げしてやろうか？ぐらいが健康的🐱#駆け出しエンジニアと繋がりたいhttps://t.co/3mtqfUZq5p

— 優さん🌷わくわく開発YouTuber (@yuu13n6) April 4, 2020

 

自分次第

私はバックエンドが軸なのでまずバックエンドで最強になりましょう。

 

DDDまとめるか〜♨️

• DDDが最強とは言わないけど。
• 変更に強いシステムは最強の要素たるのではないか
• DDDでやると工数がかかる…。ナショナルクライアント向けと言える
  参画メンバーも単価高い人入れないといけないし導入する難易度めちゃめちゃ高いな💦
• ValueObjectまでいくと工数問題でPMから支持されないし、赤字プロジェクトになりそ…。

 

DDDメリット

初期開発コストは高くなる

DDDデメリット

オブジェクトによって責務が分離されているので、探しやすくなって。
→保守が容易になる。安く改修できる

WEB-DB PRESS Vol.113

JAVAでドメイン駆動体験できる

ソースコードが書いてあるのでイメージしやすい

 

記事

• ドメイン駆動設計#1 Advent Calendar 2019
• Laravelでドメイン駆動設計(DDD)を実践し、Eloquent Model依存の設計から脱却する

これわかりやすいな🐱✨

これみながらまとめるわ。

 

DDD実装手順

1. 解決したい問題(ドメイン)に関連する人物とデータをUMLでまとめる
2. 機能をまとめる
   ・人物とデータを「人物が●●する」といったものにまとめる
   →UseCase(Service)で機能として実装する

 

 

 

UseCase層(Service)

• finalクラス
• UseCaseの実装では「■■が●●する」という主語と述語のスコープでの実装を行う
• データベースに関する記述をしない
• executeメソッドのみを有する
• １UseCase = 1クラス

 

Entity

Modelそのままではないよ。
学生というModelはデータベースに永続されている。
Entityは「奨学金を受けている学生」のように定義してEntityをつくる。

• finalクラス
• Entityのコンストラクタはprivateにする
  自身のpublicでstaticなメソッドによって自身のインスタンスを生成させる。
  →どこからでもnewされるのを防ぐ。生成元メソッドを絞ることができる
• nullableなメンバープロパティを持っている場合
  →nullをメンバープロパティに入れて初期化しておく
• バリデーション機能をつける
  このEntityを利用できる権限があるモデルなのか

 

ValueObject(VO)

• finalクラス
• Entityのコンストラクタはprivateにする
  自身のpublicでstaticなcreateメソッドによって自身のインスタンスを生成させる。
  →どこからでもnewされるのを防ぐ。生成元メソッドを絞ることができる
• バリデーション機能をつける
  型が合っているか。intやメール型などチェック

関数の引数をVO指定にすることで、連想配列の値が明確になる。推測しなくて良い。

 

Repository

２つ行う

Entity生成、DBへの保存によるEntity永続化

• finalクラス
• Interfaceを継承
• Entityを生成する
  1. newでModelを呼び出す。
  2. idでfind()するなどしてModelデータを取得
  3. データからVOを生成
  4. VOからEntityを生成に至る
• 生成するリポジトリと永続化するリポジトリはリポジトリを分ける
  →責務の分離がされて扱いやすくなる

 

テスト

• UseCase(Service)単位のテスト
• コントローラへの結合テスト

２点をPHPUnitにより行う

 

to be 最強のタイトルは知り合いの方から。

 

@see

• ゲームで学ぶ「役に立つ」ドメインモデルの考え方