DDDにおけるドメイン層オブジェクト設計の基本方針

↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。

設計/レビューで心がける点

①レイヤーの責務違反の実装をしていないか

これが最も大事！！レイヤーの責務さえ守れていれば、あとは問題があっても狭い範囲でのリファクタで済む。
例：ユースケース層にドメイン層のルール/制約に関わる実装をしている
各レイヤーの責務

②高凝集/低結合になっているか

高凝集
- クラスに関して
  - クラスの責務(何をする/何を表すクラスか)が明確か
  - クラスの責務と、保持する属性、メソッドの関連が強い(高凝集)か
- メソッドに関して
  - メソッドの責務(何をするメソッドか)が明確か
  - 意図が明白なインターフェイスになっているか
    - メソッド名：
      - 責務にあったメソッド名になっているか
      - 何が行われるのかがメソッド名から推測できるか、誤解を生まないか
    - メソッド引数：
      - 何が渡されてくるか、呼び元を追わなくても理解できるか
      - コード例
    - メソッド戻り値：何が返されるか、メソッド内を追わなくても理解できるか
      - コード例
低結合
- やりたい処理がその少ないクラスで完結できるか
  - 悪い状態： 10クラスぐらい追わないとどういう処理が行われるか理解できない

③ユニットテストを書きやすいか

高凝集/低結合だと自然とユニットテストテストが書きやすくなります。逆に、ユニットテストが書きやすいかを考えると高凝集/低結合になっていない実装に気づくことができます。ユニットテストを描こうとしたときに、多くのクラスを組み合わせないとテスト観点が意味をなさないような場合は設計に問題がある可能性があるので、設計自体を疑ってリファクタを検討します。

この記事は何か

トップページの説明をご覧ください

筆者執筆書籍

ドメイン駆動設計モデリング/実装ガイドはじめてDDDを学ぶ方、実際に着手して「難しい！」と感じている方を対象とした、DDDについての解説書です。実際の質問を元にしたQ&Aもあります。本記事の内容は本書「2.3 ドメイン層オブジェクト設計の基本方針」からの抜粋です。
ドメイン駆動設計サンプルコード&FAQ DDDに関して頻出の質問に、多くのサンプルコードを交えて回答した解説書です。モデリング、集約の実装、テストについても具体例を交えて解説しています。