ファクトリとは？
作る知識に特化したオブジェクト
一般的な開発では、オブジェクトの生成は複雑な手順を必要とします。そうした手順を独立したオブジェクトとして切り出します。
DDDにおけるファクトリでは、「ユビキタス言語を用いて集約をシンプルに生成する」という意味合いが強くなります。
DDDのファクトリのシナリオ
以下のように整合性の取れた集約を生成します。
- 特定の集約にて、別オブジェクト（主に集約を生成）
- サービスにて、別の「境界づけられたコンテキスト」のオブジェクトをローカルの「境界づけられてコンテキスト」の型のオブジェクトに変換して生成
用途
採番処理
例えば、ユーザーIDの採番処理はDBの採番テーブルなどを見に行って採番するか、シーケンスを使ったりして採番します。そういった大それた低レベル処理はエンティティオブジェクトに記述するのはDDDの観点では間違っています。
なので、Userクラスを作成する際は、Userクラスをnewするのではなく事前にUserFactoryを通じてインスタンスを生成するように実装します。
単純に生成方法が複雑なインスタンスを構築する処理をまとめるために使用
初期化はコンストラクタの役割ですが、コンストラクタは単純である方が望ましいです。
目安としては、コンストラクタ内で他のインスタンスを生成するコードを実行しなければならなくなった場合はファクトリ化した方が良いかもしれません。
SOLIDの一つのオープンクローズドを守るために使用
SOLID原則のオープンクローズドを守るために使用します。どのクラスを生成するかの条件分岐のためだけに使ったりする目的でファクトリークラスを使ったりします。
classを作るポイント
ただ、インスタンスを生成するだけで、状態は持たないのでstaticなclass、staticなメソッドのみが存在する形になります。
クラス
xxxFactoriesという名前にすれば良いでしょう。
メソッド
インスタンスの生成という意味でcreateメソッドだけ記述すれば良いでしょう。
ファクトリの存在に気づかせるには？
ファクトリを作成したオブジェクトに関しては、ファクトリ経由でオブジェクトの生成を期待します。ただ、クラスの内容だけ見てもファクトリ経由かどうか第三者は判断できないです。
生成対象のクラスとは同じフォルダ（言語によってはパッケージ）に保存しておくようにしましょう。
この記事へのコメントはありません。