第 6 章 Factories

[im-kashi]

• ドメインオブジェクトが果たすべき責務と、その（複雑な）ドメインオブジェクトを作成・再構成するという責務。 両社は異なる責務なので、別のオブジェクトとして切り離すべき（⇒ 単一責任の原則(SRP)？）
• ドメインでモデルに含まれないが、ドメイン層の（責務の）一部である。
• Factory は、内部の複雑なルールを満たしたオブジェクトを生成する事で、処理をカプセル化する。
• 「インスタンス化されるオブジェクトの具象クラスを、クライアントが参照しなくても良いようにする。」とはどういう意味か？DI の事？
• Aggregate をひとまとまりとして生成し、その不変条件を強制する。
• Factory（ファクトリメソッド）の要件
  • アトミック。
  • 生成するオブジェクトに不変条件を強制。
  • 生成される具象クラスではなく、要求されるクラスに応じて抽象化される。
• ファクトリメソッドの置き場所
  • Aggregate 内部のオブジェクトを生成する際は、root entity。
  • オブジェクトを生成するにあたって必要となるデータやルールを保持する、（異なる Aggregate）オブジェクト。 e.g. 生成物 "取引注文" に対する　"証券取引口座"　のファクトリメソッド
  • 自然な置き場所がない場合には、独立したファクトリオブジェクト。 e.g. "証券取引口座"ファクトリ
• コンストラクタを使用しても良いケース
  • 構築ルールがシンプル。
  • コンストラクタ内で他のオブジェクトを作成しない。
  • クライアントが実装に関心がある（具象クラスによってパフォーマンスが異なる場合等）。
  • 生成物が多態性を持たない。具体的な実装を選ばなくて良い場合。
  • コンストラクタが生成物に対し不変条件を強制するアトミックな操作になっている。

※ Aggregate は原則 Factory で組み立てる。

• Factory の設計ポイント
  • アトミックである事。
  • 生成物は不変条件を満たす事。 → オブジェクトの変遷を認めると不変条件が満たされないケースが出てくる。この場合は不変条件が満たされなくても良い？それともそもそもその不変条件が適切ではない？
  • 生成処理に失敗した場合の一貫したコーディング規則の採用。
  • 抽象型を引数に取る。
• 不変条件の置き場所は、Factory か 生成物か。
  • 基本的には生成物側。
  • 生成物が Aggregate なら Factory に置いた方が良い。
  • 不変な属性や Value Object の不変条件は生成時にのみ適用されれば十分なので、Factory 側に置く方が理に適う。
• Value Object に Factory は必要？

[im-kashi]

議論した事の断片

生成される具象クラスではなく、要求されるクラスに応じて抽象化される。

Factory は抽象型を返し、その具象についてクライアントは知るべきではない（依存すべきではない）という事。

生成物は不変条件を満たす事。 → オブジェクトの変遷を認めると不変条件が満たされないケースが出てくる。この場合は不変条件が満たされなくても良い？それともそもそもその不変条件が適切ではない？

生成されるドメインオブジェクト（Entity, Value Object 等）は、生成時・変遷時共に不変条件を満たしているべき。 不変条件が満たされないオブジェクトは、ドメインオブジェクトではない。

抽象型を引数に取る。

引数の具象型に依存させない為。

生成物が Aggregate なら Factory に置いた方が良い。

反対意見。Aggregate は一般的に変遷するが、不変性は常に強制されるべきなので、Factory ではなく Aggregate（生成物）側に不変条件を置く方が良い。

Value Object に Factory は必要？

Value Object はシンプルである事が求められているので、Factory は要らないよね。

他にあった議論を覚えていましたら、記載をお願いします。