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