DDD/Pause for Refactoring - Java EE勉強会

リファクタリング中:Cargoシステムの別設計案「AGGREGATE」(ページ) †

モデルや設計は製造の前にあるものではない、良くするためリファクタリングはどんどんやろう。

現時点で、そこそこ動くしモデルをちゃんと反映しているけれども、当初それほど重要に見えなかった問題が、だんだん厄介になり始めている。そのうちの１つを振り返って、後知恵の利点を生かして設計を改善していこう。

Handling Eventを追加するとDelivery Historyの更新が必要になり、他のユーザが同時にCargoを修正すると失敗or遅延の恐れがある。干渉なしに追加したい。

Handling EventsのDelivery Historyコレクションをクエリとして実装すると、干渉なしに追加できる。

Handling Events用のREPOSITORYを追加。必要に応じてクエリを最適化したり追加したりすることも可能。

ただしオブジェクトデータベースの場合だと、関連やコレクションを走査する方が速い。

代替案や設計のトレードオフはいたるところにある。重要なポイントは、同じモデル内でのみ自由であるということ。VALUESやENTITIES、AGGREGATESのモデリングによって、設計変更の影響を減らせる。

リマインドですが、「Handling Eventを追加するとDelivery Historyの更新が必要になり」のくだりは、Handling EventにDelivery HistoryのListを持たせようという実装上の判断を以前にしていることと関連しています。そのため、リストのエレメントを追加するために毎回Handling Eventにアクセスしなければならず、当然AGGREGATE ROOTであるCargoをロックしなければいけない、というつながりです。 -- 和智? 2008-11-29 (土) 01:56:14