前回の続き
関連を設計
問題は双方向の関連。
検索なんかで関連づけられているだけならRDBのクエリで実現すればよいので、関連は不要。
ビジネスをしっかり理解すれば減らせる関連もありそう。ビジネス上必要ないのに関連付けられているならば削除する。
あとは、循環参照になっている場合が問題。
例では、
[貨物]->[配送記録]->[荷役イベント]->[貨物]
という参照パターン。
解決策としては[配送記録]<>->[荷役イベント]と、配送記録に荷役イベントを含んだリストを与えることで循環参照はそのままだが、実装上問題ないようにしているようです。(これで問題起きないんだっけ？っていう疑問は残りますが・・・)
そして、将来的には、貨物をキーにデータベースを検索するようにするかもしれないとは言っています。
最初からそうしない理由は、記録を問い合わせることが多いとみられるから直接参照しているほうがよいということ。記録への問い合わせが稀であれば、データベースへの検索の方にしたほうが、オーバーヘッドは減るでしょう。
そこは設計におけるトレードオフということですね。
集約の境界
独自の同一性があるものをルートに選択しています。
そのルート(例では[貨物])からどこまでを境界にするかが検討されていますね。
基準としては、値オブジェクトはもちろん境界内、エンティティでも独自の同一性がない、グローバルにアクセスされないものは境界内に設定していますね。
明日も引き続き読んでいきます。