ddd-factory

1 行でまとめると

ファクトリーは、構築そのものが複雑な場合やドメイン上の意味を持つ場合に、完全で有効な集約または値オブジェクトを作成するための知識をカプセル化します。

このスキルを使う場面

• 複数のサブオブジェクトを組み立てる必要がある場合（新しい Order は明細項目、初期ステータス、作成日時を持って誕生します）。
• 単純なフィールド検証を超える不変条件を適用する必要がある場合（新しい Subscription は有効な Plan と、キャンセルされていない Customer を参照する必要があります）。
• 作成という行為に、ユビキタス言語でドメイン上意味のある名前がある場合（Order.placeFor(customer, items)、Account.openFor(applicant)）。単なる new Order(...) ではありません。

このスキルを使わない場面

• コンストラクターだけで必要な処理をすべて実現できる単純なオブジェクト。
• エンティティ上の静的作成メソッドで十分な場合は、作成ロジックが生成されるオブジェクトに属さない場合、または作成時に複数の集約が連携する場合に限って、独立したファクトリークラスにします。
• 書こうとしている「ファクトリー」が単に new を呼び出すだけの場合、それは儀式的な記述であり、カプセル化ではありません。

主な内容

一般的な 3 つの形を、仕組みが最も簡素なものから順に紹介します。

エンティティ上の静的作成メソッド。 Order.placeFor(customer, items)。作成ロジックが生成される型に自然に属する場合に推奨されます。メソッド名にはユビキタス言語を使います。新しいクラスを作ることなく、必要な構築処理をカプセル化します。

専用のファクトリークラス。 createFor(applicant, plan, paymentMethod) メソッドを持つ SubscriptionFactory。たとえば、他の集約の呼び出し、参照データの検索、複数の入力の調整など、生成されるエンティティには属さない調整処理が作成に伴う場合に使います。

ビルダー。 段階的に構築するための流れるようなビルダーです。使用は控えめにしてください。集約に多くの任意フィールドがあり、最終的な build() のステップで検証を実行する必要がある場合に、ビルダーが効果を発揮します。ビルダーが無効な中間状態を返さないようにしてください。build() は完全に検証された集約を返すか、失敗する必要があります。

ファクトリーの責任は、有効な集約を返すところまでです。永続化はリポジトリーの役割です。1 つのファクトリー内で作成と永続化を混在させると、レイヤーの境界が曖昧になります。

判断のヒント

• まずはコンストラクターまたは静的メソッドを使います。エンティティが担うには処理が複雑すぎる場合や、複数の協力オブジェクトが関与する場合に限って、ファクトリークラスにします。
• ファクトリーのメソッド名には、ユビキタス言語を使います。create、make、instantiate ではなく、placeOrder、openAccount、issueRefund のようにします。
• ファクトリーがデータの読み込みや永続化を必要とする場合、関心事が混在しています。ファクトリーはアプリケーション層に属する可能性があります。または、すでに読み込み済みの入力を受け取るようにします。

アンチパターン

• 作成とライフサイクルの管理が混同される、永続化も行うファクトリー。
• コンストラクターではできない処理が create() に何もないにもかかわらず、反射的にエンティティごとに FooFactory クラスを作ること。
• 「FactoryFactory」という間接化。ほとんどの場合、コードベースが過剰に設計されている兆候です。
• 中間状態を返すビルダー。呼び出し側が構築途中の Order を保持し、そのメソッドを呼び出せてしまいます。

関連項目

• ddd-entity — ファクトリーが通常何を作成するか。
• ddd-aggregate — ファクトリーは集約全体を生成し、途中までの集約は生成しません。
• ddd-repository — 境界。ファクトリーは作成し、リポジトリーは永続化します。

参考資料

• Evans, Domain-Driven Design（2003 年）、第 6 章（ドメインオブジェクトのライフサイクル）。