【ミライトデザイン社内勉強会#20】「IDDD本から理解するドメイン駆動設計」輪読会~第11章「ファクトリ」~

前回の記事

【ミライトデザイン社内勉強会#19】「IDDD本から理解するドメイン駆動設計」輪読会~第10章「モジュール」~ - Qiita

実践DDD本 第11章「ファクトリ」～複雑な生成をユビキタス言語でシンプルに～ (1/3)：CodeZine（コードジン）

集約の取得や生成はリポジトリが行うイメージだったけど、集約から他の集約を生成する時にDBに保存しているデータが欲しくなった場合はどうするの？

p2

• Applicationサービスとかで、あらかじめ必要なデータをRepositoryやQueryServiceで取得して置いて、メソッドに渡すのでは？

• リポジトリはデータの永続化や再構築は行うが、集約の生成自体は行わない

  • 再構築と生成は別
    • 生成は不変条件が必要、再構築はチェック済のデータを取得するだけなので、不変条件のチェックはいらない。
    • 再構築する場合は、リポジトリからnewしてくればいい

• 使い方はコンストラクタでnew する時と同じ

  • Factoryを使う側はコンストラクタで生成する場合と同じようにFactoryからインスタンスを取得する
    • コンストラクタでインスタンスを生成する場合とはちがって、生成する時の条件を指定できる

• Repository = 倉庫

  • 倉庫なので、生成はしない
  • 再構築
  • データの取得

• Factory = 工場

  • 生成する
  • Factoryで生成したものをRepositoryに保存する

• Factoryを置く場所

  • コンストラクタ
  • 集約上のFactory
  • サービス上のFactory

• ファクトリでは集約の生成を同じ手続きで行うようにする

ファクトリで不変条件を満たすとあるが、オブジェクト側でその条件を保証するんじゃないの？

p2

不変条件を満たすファクトリ

• 他のエンティティの不変条件なので、生成前にオブジェクト自身では保証できない

優れたファクトリは「生成される具象クラスではなく、要求される型に応じて抽象化されないといけない」ってどういう意味

p3

• 返り値の方を具象クラスでなく、インターフェースで定義しろみたいな話かな？
  • ちょっと日本語難しくてわからん。

ファクトリが不要な条件

ここまでファクトリの必要性を説いていますが、ファクトリが不要な場合もあります。
DDD Quickly日本語版では、以下の条件が示されています。

• オブジェクトの作成処理が複雑でない。
• オブジェクトの作成処理内で他のオブジェクトを作成しない。必要な属性はすべてコンストラクタで設定する。
• クライアントはオブジェクトの実装に興味がある。例えば、ストラテジパターンを使って処理を選択したい。
• クラスは具体的な型であり、その型から派生しているクラスはない。したがって具体的な実装を選ばなくていい。

次回

【ミライトデザイン社内勉強会#21】「IDDD本から理解するドメイン駆動設計」輪読会~第12章「リポジトリ」~ - Qiita