貨物輸送ドメインにおいて関連をデザインする（p.169） †
要約 †
- 導入（第一段落）
- もともとのクラス図に示された関連では、関係の方向について定められていない。しかし、双方向の関連はデザインにおいて問題を引き起こす。
- また、関連の方向はドメインについての洞察を表現するものであり、モデルそれ自体を深めるのだ。
- CustomerとCargoの関係（第二段落）
- Customerが全てのCargoを直接参照することは好ましくない。
- 同じCustomerが繰り返しCargoを送った場合にわずらわしいことになる。
- Customerという概念はCargoに限られるものではなく、多くのオブジェクトと関連するのだから、特定役割に縛らない方がよい。
- 詳しい話はREPOSITORYの章を参照。
- Handling EventとCarrier Movementの関連の方向（第三段落）
- Handling EventとCarrier Movement間の矢印がHandling EventからCarrier Movementに向けられている。
- これは追跡する必要があるのはCargoだけ、という、業務に対する理解に基づいている。
- 循環参照について（第五段落）
- CargoはDelivery Historyを知り、Delivery Historyは一連のHandling Eventを持つ。そして、Handling EventはCargoを参照する。
- 循環参照は多くのドメインにおいて論理的に存在するものであるし、デザインにおいてさえも論理的に存在する必要があることがある。しかし、メンテナンスは容易でない。
- 「同じ情報を二箇所に持って、同期を保たなければならなくなる」状況を避けるという実装時の判断によって問題を解決することが可能。
- 当初はDelivery HistoryにHandling EventのListを持たせていた。
- しかしそのうち、データベースに対してCargoをキーとした検索を行なうことで、コレクションを削除したくなるだろう。
- この辺りの話はREPOSITORYを選択するときにまたとりあげる。
担当者のつぶやき †
- p.170の図7.2を見ながら読んでください。
- 循環参照や双方向の関連について、「ＳＱＬで解決する」と言われてしまうとちょっと肩透かしを食らったような気がするのは僕だけでしょうか？
- 関連の管理においてはREPOSITORYが強力に機能するようなので、そこでの議論に期待します。
- "Implementation choise "を「判断」と強めに訳しています。
- "Assosiations"のページを作ってしまいました・・・消し方が分かりませんorz
みんなの突っ込み †
