データベースから離れて集約を考える
集約に関して、GuildWorks増田さんからアドバイスをいただきました。
ありがとうございます！
集約の話は、モデル/オブジェクトの実装/データベースへの格納、の三つが同時に語られているから。読み解くには、いったんデータベースの話を無視すると良いです。全てがメモリ上のオブジェクトで表現/操作できるものとして、オブジェクトのネットワークをどこで分割するかの議論として読む。
オブジェクトの「参照」と「変更」の議論は、テーブルの参照関係とデータベース更新の話ではない。
メモリ上のオブジェクトだけを使った、判断/加工/計算のロジックを、どういう単位で整理するかが主眼。
エヴァンスのオブジェクト脳の議論を、手続き型の発想で読むから、わけがわからなくなるw。
どうしても、トランザクションやロックの話が出て来るし、後のリポジトリの話題にも関わってくるため、集約の話しになる際には、データベースの話題にも触れる必要があるのは仕方ないですよね。
ただ、よく読むと、集約の境界やルートの決め方の話では、一切データベースの関連は考えず、ドメインを中心に話しが進みます。
実際、この種の問題に対するバランスの取れた解決策を見つけるのには、ドメインに対する深い理解が必要である。(第二部 第六章 より)
なので、集約をきちんと理解するためには、データベースから離れて、ドメインを中心に、モデルのすべてがメモリ上に展開されているオブジェクトで表現できるものとして考えるのが第一です。
購入注文の例もそのようになっていますね。
最初の方はデータベースの話しになっていますが(むしろデータベース中心に考えていたらデットロックかかってどうしようなんていう展開になっていますね)、モデルの検討のシーンでは、ビジネスの知識を中心に検討しています。
１.商品は多くの購入注文で使用される
2.商品に対する変更は購入注文に対する変更より少ない
3.・・・
このモデルと一致した実装をすれば、購入注文とその品目に関連する不変条件は保証されるだろう。
つまり、モデルをドメイン中心に考えることによって集約が定義できるということです。モデルが変更される頻度、タイミングや影響範囲などを考慮することで集約の範囲が見えてきます。
集約のモデルを作成する際は、一旦データベースは置いておいて、ビジネスの知識から考えましょう。