DDDでの失敗談

近々同僚とLT大会をするので話すことをMarkdownで書いてみたので投稿。

DDDでの失敗談

DDDを1年半くらい実践してきて色々成功したこと失敗したことがあった。 この場では失敗談を共有してアンチパターンへの対処法をお伝えしたい。

ドメインしっかりと設計すれば変更少なくてすむだろう→そんなことはなかった

ドメインの設計見直しタイミングは以下のケースがあった。

  • 仕様を固めていく上で他の仕様も変わるケース
  • ユーザテストの意見反映で仕様が変わるケース
  • 実装を進めていてより良い設計を思いついたケース

意外とコロコロ変わる。 悩んでベスト設計を目指すのではなく、ベター設計で速度を優先したほうが良い。

ユビキタス言語決めたら変更はないだろう→変更入りまくり

  • 名前が学術名で難しいので分かりやすい名前に変えた
  • デザイン進めて行く上で変わった
  • 他アプリでの名称違うからそっちの反映
  • 監修担当から変更要望反映

ユビキタス言語は変わる。 変わらないように努めるべきだが変わる可能性は充分にあることを留意する。

通信も結局はデータ操作だからData層に入れられそう→Domain層でHttpステータスに応じて色々したい…

  • 通信処理もDB操作と同じくset/getのイメージで、returnもValue/nullで扱えそう。通信結果はData層内で隠蔽できそうだと思った。
  • でもHttpステータスに応じてアクション変えたいね。
  • やっぱりドメイン層で扱いたい。

通信結果もビジネスロジックとしてDomain層で扱いたい要望はあるので隠蔽しすぎないこと。 個人的にはCleanArchitectureの図のように、Data層/Web層は分離しとくと分かりやすくて良いと思う。

ビジネスロジックどこ書けばいいかわからん…とりあえず専用クラス作ってそこにメソッド書くか→Entityがただのデータの入れ物化

ビジネスロジックを書く際は既存のEntity/ValueObjectで担当できるか検討する。 担当出来ない場合、サービスクラスとして実装する。UseCaseには書かない。

まとめ

  • ドメインはアプリを作っていく過程で変わる可能性は充分にあるし、後日より良い設計を思いつく可能性が高い。設計に迷ったら時間を掛けすぎず一旦思いついた限りの内容で実装進める。
  • ユビキタス言語はプロジェクト初期に確定するのは難しい。変わらないように努力しつつ、後々変わる事も意識しておく。
  • ドメインは通信結果も意識する。Data層に押し込めすぎないようにする。
  • 振る舞いを考えるときは既存のEntitiy、ValueObjectで探すこと。安易にロジックをUseCaseなりに押し込めない。