Factory

直訳すると「工場」

1つのAggregateに対し、1つのFactoryを定義する

Factoryという概念が存在する理由は、以下2つを分離して考えたいため

こちらがFactory

こちらはAggregateそのもの

つまり、「Aggregateの生成」自体が複雑なものだとしても、それをAggregateの内部構造に影響させたくない

そこで、生成自体の責務を独立させている

Aggregateの利用者は組み立て方を知らなくて良い

Aggregateは複数のEntityの集合なので、組み立て方は複雑になることが多い

利用者は、どのFactoryを呼べばよいかさえ知っていれば良い

組み立て方をカプセル化する

Factoryを1つ呼ぶだけで完全なAggregateが得られないといけない

複数のmethodを呼ばないと作れない、ようにはしてはいけない

具体的なFactoryの実装方法としては、

何かしらのEntity classのmethodを定義する

何かしらのEntity専用のFactoryのみを持ったclassを定義する

Facotryを実装するためのデザインパターン

参考

生成用と、再構築用で異なるfactoryを用意することもある

生成は、例えばユーザーの入力などから生成する時など

e.g. 注文時にOrderを生成

identityは、自動生成するか、何らかの入力(e.g. 電話番号)を使うか

throwしたり、nullを返したり

再構築は、例えばDBに入っているデータを復元するときなど

この時は、identityが既に確定している

満たさなかったということは、既にDBに入っているデータがそもそもおかしいということ

エラーにすれば良いとかいう単純な話ではなくなる

本来は後者の中にあるべきものを、生成の都合で前者に書いてしまっていいのか？

ドメインに直接関係のある概念ではないが、ドメイン層に置く