Aggregate
必ず守りたい強い整合性を持った関連するEntityのまとまり データを変更するための単位として扱われる
必ずまとめて取得し、
必ずまとめて更新する
集約が、永続性の最小単位になる
「良い集約の切り方」はドメイン知識がかなり必要そうmrsekut.icon
何の話をしているのか？
Entity同士の関連性の話をしている
アプリケーション内に存在するいくつものEntityは独立に並列に存在しているわけではない
Entityの集合に構造を入れる
Entity同士がお互いに好き勝手に依存し合っていると、削除や更新をした場合に同一性の担保がしづらくなる
例えば、あるUser Objectを削除した時に、そのUserが住んでいたAddressを保持するAddress Entityの扱いはどうするか？という問題がある
Addressも同時に削除するのか？
そこに他のUserも住んでいたら、そのUserの住所が空になる
Addressは削除せず置いておくのか？
そこに誰も住んでなかったら無意味なAddressのデータが残り続けることになる
図を見るとわかりやすい
https://gyazo.com/b051ffa169a9c1ea2fa2cb35797304c1
集約は、1つ以上のEntityの集合のこと
これのみが集約の外部のEntityらとのやりとりをする
上図では、自動車集約のrootは自動車なので、
外部の顧客などは、タイヤなどにはアクセスできない
集約の内部のEntity同士は互いに関連しあっていても良い
root以外のものが変更されたら、rootも変更されることになる
タイヤの1つが変更されたら、自動車も新しく作られることになる
immutableだからmrsekut.icon
rootが削除されたら、内部も全部削除される
GCがあるなら参照がそもそも自動車にしかないので、自動的にこれは達成される
自動車の所有権配下にタイヤなどがある
タイヤなどは、集約の内部でIdentityを持ったり持たなかったりする
自動車がglobalに同一性を持つのに対し、タイヤの同一性は集約のスコープに限った話で良い
他のEntityは、Aggregate Rootから関連を辿ることでのみ取得できる
例えば上の例では、SQLを書いてタイヤを取得してはいけない
↓これやりだすとめちゃくちゃ複雑になる気がする
root以外の集約内部に、外からアクセスできないようにする、というのを型で上手く表現できないかな？mrsekut.icon
あるEntityが複数の集約に入ることはあるのか？
と思ったがたぶんないだろうmrsekut.icon
あるならそれはもはや別のEntity(instanceの話ではなくclassの話)として定義すべき
参考
AggregateはEntityの一種