REPOSITORIESの選択 (p.172) †
要約 †
- 導入
- AGGREGATEのルートとなるENTITYは5つ。
- REPOSITORYを持つことが許されるのはこれだけなので、限定して考える。
- CustomerとLocation
- REPOSITORYを決める上では、アプリケーションの仕様にさかのぼる必要がある。
- 様々な役割を果たすCustomerを選択する必要⇒Customer Repository
- Cargoの目的地を特定するためのLocationを探す必要⇒Location Repository
- Carrier MovementとCargo
- あるCargoが載せられたCarrier Movementを検索する必要⇒Carrier Movement
- どのCargoが載せられたかをシステムに伝える必要⇒Cargo Repository
- Handling Eventについて
- Handling Event Repositoryが存在しないのは以下の理由による。
- Delivery Hisoryとの関連を実装することになっている。
- あるCarrier Movementに何が載せられたかを知る必要はない。
担当者のつぶやき †
- 素朴に考えると、「データモデルさえしっかり作っておけば、あとはSQLでご自由に」というのもそれはそれでありな気もします。ただ確かに「何をどう検索するのか」という情報がモデル上に表現されているのは明快だと感じました。
- REPOSITORIESの章でも言われていたことだと思いますが、REPOSITORYについては「保管場所」というよりは「検索の拠点」という観点から理解するのが正しいようですね。
みんなの突っ込み †
- Delivery Hisoryとの関連で実装されるHandling Eventが、CargoのAGGREGATEに属さない(Figure7.4で囲まれていない)のはなぜなんでしょう? -- 中村?