AGGREGATEの境界 (p.170) †
要約 †
- 導入−エンティティCargoへの着目
- Customer、Location、Carrier Movementは独自のアイデンティティを持ち、多くのCargoによって共有されるので、AGGREGATESのルート要素になる。
- CargoがAGGREGATEのルートとなることは明らかだが、どこに境界を引くかという点には一考を要する。
- CargoのAGGREGATE
- CargoのAGGREGATEは、特定のCargoがなければ存在し得ないものを全て含むことができる。
- Delivery History・Delivery Specification・Handling Event
- Delivery Historyは境界内と考えられる。
- Delivery HistoryをCargoと関係なく検索する必要が無い。
- Delivery HistoryのアイデンティティはCargoから導かれる。
- Handling Eventについて
- 二通りの検索方法が考えられる。
- Delivery History内にコレクションを持つ方法に対する代替手段
- 特定のCarrier Movementに紐づく全てのオペレーションを検索
- 前者であれば、CargoのAGGREGATE内と考えられる。
- 後者であれば、Cargoを扱うこと自体がCargoから切り離されても意味を持つということになる。
- したがって、Handling EventはAGGREGATEの外部とする。
担当者のつぶやき †
- AGGREGATEの境界を決定する際の根拠が、エンティティ間の本来的な性質ではなく業務上の論理的な意味関係である、という点はEvansの言うモデルを考える上でも重要だと思いました。
- 業務的には明らかにAGGREGATEの境界内にあるにもかかわらず、そのエンティティに対してグローバルな検索を行なう仕様って結構あると思うのですが、そういう場合はどう考えるのでしょうか。。
- 例えば、「企業」-「部署」-「営業履歴」という関係がある場合に「担当者」と「日付」で「営業履歴」一覧を見たいというような場合。
- AGGREGATEの単位は細かくなっても良くて、そういう場合には、AGGREGATEのルート同士の関係モデルが作られるということでしょうか。
みんなの突っ込み †