実践DDD本 第11章「ファクトリ」～複雑な生成をユビキタス言語でシンプルに～

• 実践DDD本 第10章「集約」～トランザクション整合性を保つ境界～

ファクトリとは

　開発における一般的な「ファクトリ」とは、複雑になりがちなオブジェクト群を簡単に組み立て、呼び出し側に対して内部構造を隠して生成する仕組みのことを指します。これに対して、DDDのファクトリでは「ユビキタス言語を用いて集約をシンプルに生成する」という意味合いが強くなります。そのためDDDのファクトリとしては、下記のようなシナリオが中心となります。

1. 特定の集約にて、別のオブジェクト（主に集約）を生成
2. サービスにて、別の「境界づけられたコンテキスト」のオブジェクトを、ローカルの「境界づけられたコンテキスト」の型のオブジェクトに変換して生成

　一般的なプログラミングパターンでもオブジェクトを生成するという意味合いは同じですが、DDDの場合は、ユビキタス言語にて業務を表現し、見せるべきでない情報を保護し、整合性のとれた集約を生成します。

ファクトリを使う理由

　ファクトリを使う理由として、IDDD本では、エヴァンス氏の次の説明を引用しています。

　複雑なオブジェクトと集約のインスタンスを生成する責務を、別のオブジェクトに移すこと。その別のオブジェクトは、それ自体ではドメインモデルにおいて何の責務も負っていないかもしれないが、それでもドメイン設計の一部であることに変わりはない。

　エヴァンス氏は、「車のエンジン」や「銀行口座」を例にファクトリを利用する理由を紹介しています。エンジンの場合「複数部品を使ってエンジンを組み立てたてる処理」と「回転する処理」を分けています。銀行口座の場合「口座の開設処理」と「口座の取引処理」を分けています。このように複雑な生成処理を分離することで、全体を理解しやすくできることがファクトリのメリットと紹介しています。

IDDDにおけるファクトリの例

　IDDD本においては、別の集約にファクトリメソッドを用意する方法を主に紹介しています。つまり「ファクトリ」は「集約の振る舞い（メソッド）」となります。

　SaaSOvationでは「ユーザー」を生成するために、「テナント」集約に「ユーザーを登録する」というファクトリが存在しています。このメソッドを呼び出すと、テナントの情報とクライアントから渡された引数の情報を使用して「ユーザー」が生成されます。そして（そのオブジェクトを「テナント」集約に保持するのではなく）呼び出し側のクライアントに返します。

ファクトリの設計

　ここからはオブジェクトの生成のパターンについて見ていきましょう。まずオブジェクトを生成する場合、クライアント側からコンストラクタを呼び出すという単純なケースが考えられます。これを含めると、オブジェクトの生成パターンとしては、次の3パターンが想定できます。

　これらの特徴について順番に紹介していきましょう。