DDD
ドメイン駆動設計

ちょっとずつ読むドメイン駆動設計 第ニ部 モデル駆動設計の構成要素 第五章 ソフトウェアで表現されたモデル2

More than 1 year has passed since last update.

関連

モデリングと実装との間の相互作用は、オブジェクト間の関連を見た時に、特に油断ならないものとなる。(第二部第五章より)

現実を見たとき、大体の関連が多対多であり、双方向ですよね。

例えば、「注文」と「商品」の関連を考えた時、
"注文にどんな商品が含まれているか"で考えれば[注文]->[商品]ですが、逆に"この商品はどんな注文がされているか”で考えれば[商品]->[注文]です。

このように現実に即して双方向や多対多に関連づけてしまうことに対し、

一般的な関連は、そこにある関係の性質について、ほとんど何も伝えない(第二部第五章より)

とEvansは言っています。

実装面でみても双方向の関連や多対多の関連は複雑で管理がしずらくなります。
なので、関連をできるだけ制限する方向で考えましょう。
そのやり方は

  1. 関連を辿る方向を強制する。
  2. 限定子を付加して、多重度を効果的に減らす
  3. 本質的ではない関連を除去する

まず、アプリケーションの要件が双方向に辿ることを求めないなら、一方向でいいわけです。

ドメインを理解することで、本来はどちらの方向性が重要であるかが、明らかになる場合がある。(第二部第五章より)

先ほどの「注文」と「商品」の関連で言えば、
"注文にどんな商品が含まれているか"は重用なドメインの要件で[注文]->[商品]の関連は必要となりますが、"この商品はどんな注文がされているか”は商品をキーとして、注文のリストが抽出できればよいわけで、そもそも関連づける必要がないわけです。

こうして、関連の方向を強制したり、除去したりで、関連を整理して容易な設計にしていきます。

2の限定子については、書籍の例がわかりやすいです。(実用的な例かどうかは別として・・・)

国と大統領の関係の例ですが、1つの国に複数の大統領がいるため[国]1->*[大統領]ですが、ある期間には一人の大統領しかいませんので、在任期間の限定子を付与することで、1対1にすることができます。

明日はどう実装と関連のモデルを結びつけるかを読んでみます。