Factory
直訳すると「工場」
Aggregateを生成、または再構築する
Invariant(不変条件)を満たした状態で生成する
1つのAggregateに対し、1つのFactoryを定義する
Factoryという概念が存在する理由は、以下2つを分離して考えたいため
Aggregateの生成
こちらがFactory
Aggregate単体の責務
こちらはAggregateそのもの
つまり、「Aggregateの生成」自体が複雑なものだとしても、それをAggregateの内部構造に影響させたくない
そこで、生成自体の責務を独立させている
Aggregateの利用者は組み立て方を知らなくて良い
Aggregateは複数のEntityの集合なので、組み立て方は複雑になることが多い
ただ組み合わすだけでなく、Invariant(不変条件)を満たしている必要がある
利用者は、どのFactoryを呼べばよいかさえ知っていれば良い
組み立て方をカプセル化する
Factoryを1つ呼ぶだけで完全なAggregateが得られないといけない
複数のmethodを呼ばないと作れない、ようにはしてはいけない
この性質を『エリック・エヴァンスのドメイン駆動設計』.iconでは「アトミックである」と言っている
具体的なFactoryの実装方法としては、
smart constructor
どこかに書いていたわけではないがFPでは、これだろうmrsekut.icon
何かしらのEntity classのmethodを定義する
こういうものを、「factory method」と呼ぶ
何かしらのEntity専用のFactoryのみを持ったclassを定義する
factory methodを何らかのEntityに歪に実装するぐらいなら、それ専用のclassを作ったほうがいい
Facotryを実装するためのデザインパターン
Factoryパターン
FactoryMethodパターン
AbstractFactoryパターン
Builderパターン
参考
/mrsekut-book-4798121967/175 (ファクトリ(FACTORIES))~
#WIP
生成用と、再構築用で異なるfactoryを用意することもある
生成は、例えばユーザーの入力などから生成する時など
e.g. 注文時にOrderを生成
identityは、自動生成するか、何らかの入力(e.g. 電話番号)を使うか
Invariant(不変条件)を満たさなかった時はエラーにする
throwしたり、nullを返したり
再構築は、例えばDBに入っているデータを復元するときなど
この時は、identityが既に確定している
Invariant(不変条件)が満たなかった時にどうするか
満たさなかったということは、既にDBに入っているデータがそもそもおかしいということ
エラーにすれば良いとかいう単純な話ではなくなる
/mrsekut-book-4798121967/184
Invariant(不変条件)のロジックはどこに書くべきか?
factory内に書く?Aggregate Root内に書く?
本来は後者の中にあるべきものを、生成の都合で前者に書いてしまっていいのか?
/mrsekut-book-4798121967/183
ドメインに直接関係のある概念ではないが、ドメイン層に置く