Java EE勉強会

DDD / Segregated Core

DDD

担当：中村

SEGREGATED CORE (p.428) †

SEGREGATED CORE （中核の隔離）

要約 †

【問題サマリ】

  • モデルにおける要素にはCORE DOMAINに含まれるものもあれば脇役を演じるものもあります。中核の要素は汎用的な要素に密結合しているかもしれません。中核の概念的な凝集度は強くないかもしれないですし見えにくいかもしれません。このような乱雑さやもつれにより中核は成長を妨げられます。設計者はもっとも重要な関係を明確に理解できないため、設計は劣ったものになります。

【問題の解決方法についての説明】

  • サブドメインを見出すのは難しく、取り組む価値がないこともあります。しかし、そうしなければCORE DOMAINは残留物でもつれたままです。

Therefor:

【解決方法サマリ】

  • 中核の概念を脇役の概念（明確に定義されていないものを含む）から分離するようにモデルをリファクタリングしなさい。そして他のコードへの結合度を小さくすると同時に中核の凝集度を高めなさい。汎用的または脇役的な要素を他のオブジェクトに分解し他のパッケージに配置しなさい。それは、強く結びついた要素を分離するといった方法でモデルをリファクタリングすることを意味するかもしれません。

【結果、実装上の検討事項、サンプル】

  • 凝集度の高いサブドメインの背後には未分化の固まりがあり、その場にとどまりつづけたり、主要なクラスからなるパッケージに配置されたままになっています。
  • SEGREGATED COREへの取り組みが実行されつづけるのならば、最終的には、多くの残留物がGENERIC SUBDOMAINの要素となり得ます。
＊＊＊

SEGREGATED COREへとリファクタリングするために必要なステップは次のとおり。

  1. COREなサブドメインを認識する。
  2. 関連するクラス群を新たなMODULEに移動する。MODULEにはそれらに関連するコンセプトに因んだ名前をつけておく。
  3. 直接的に概念を表現しない機能とデータを分離するようにリファクタリングする。削除したものは他のパッケージに属するクラスに加える。COREなサブドメインを磨くことと、COREなサブドメインから他パッケージへの参照を明示的で説明的なものにすることに集中し続ける。
  4. 新しいSEGREGATED CORE MODULEをリファクタリングし、関連と相互作用をシンプルでコミュニケーティブなものにする。そして、他のMODULEとの関連を少なくし明確にする。
  5. SEGREGATED COREが完了するまで他のCOREなサブドメインについても繰り返す。

The Costs of Creating a SEGREGATED CORE （SEGREGATED COREを作成するコスト） †

  • COREを隔離することにより、COREは、あいまいだったり複雑だったりする密結合なCOREでないクラス群と関係を形成することがあります。しかし、CORE DOMAINを明確にしたり扱いやすくしたりすることの利点はこのコストを上回っています。
  • SEGREGATED COREの作成により、よく凝集されたMODULEが壊れることがありますが、それはCORE DOMAINの凝集度を高めるための犠牲です。
  • COREを隔離するには多くの作業が必要で、可能性としては全システムを変更することになるかもしれないと認識しておく必要があります。。
  • SEGREGATED COREに取り組むのはシステムにクリティカルな巨大なBOUNDED CONTEXTがあるときです。そこでは、モデルの本質的な部分が脇役によってあいまいにされています。

Evolving Team Decision （チームの決定を進化させる） †

  • 戦略的な設計上の決定と同様、チーム全体がSEGREGATED COREに向かわなければいけません。課題は、チームの決定を固定することなく全員に同じCOREの定義を使わせることです。CORE DOMAINは進化するので、SEGREGATED COREに取り組むことで新しい洞察を得られます。
  • 得られた洞察はフィードバックされるべきですが、これはチームで共有されなければいけません。そのため、共同決定のためのプロセスが何であれ、繰り返しチームの進路を訂正できるほどにアジャイルでなければいけません。また、コミュニケーションは全員にCOREの1つの見方を促すほどに効果的でなければいけません。

Example Segregating the CORE of a Cargo Shipping Model （貨物出荷モデルのCOREを隔離する） †

  • 貨物出荷調整のソフトウェアを題材にします。（Figure 15.2）
  • まずは肝心なところに目を向けるのがいいです。それは、価格や伝票になるでしょう。しかし、本当に必要なのはDOMAIN VISION STATEMENTを見ることです。そこにはこうあります。
操作の見える化を進め、顧客の要求を速く安全に満たすようなツールを提供する。
  • このアプリケーションは営業部門のためではなく、会社のフロントに立つオペレーターのためのものです。そのため、お金に関することは脇役に追いやりましょう。だれかがすでにBillingパッケージへと切り出しているので、これはそのまままにし、脇役であると認識します。
  • 貨物のあつかい、つまり配送に注目すべきです。配送に関するクラスを抽出するとDeliveryと呼ばれる新しいパッケージにSEGREGATED COREができます。（Figure 15.3）
  • ほとんどはパッケージを移動しただけですが、いくつかモデルが変更されています。 Customer AgreementがHandling Stepを制約するようになりました。効率や正確な配送に目を向けることで、Customer Agreementの下での制約は必須のものでモデルの中で明示すべきだと明らかになったのです。
  • また、Customer AgreementがCargoと直接関連を持つようになりました。実際の配送では、Cusotomerと協定の操作とは関係がないからです。このため、CusotomerをCOREから取り除くことができます。
  • 議論が分かれるのはLegをCOREに残すかどうかでしょう。私はCOREを小さくすることを好みます。また、LegはTransport Schedule、Routing Service、LoacationといったCOREには必要とされないものと強く結合しています。そのため、LegはCOREには含めませんでした。
  • さて、SEGREGATED COREを得られ、リファクタリングは完了しました。しかし、ShippingパッケージにはCOREから抽出されたもの以外のすべてが残っています。引き続き、リファクタリングを続けることができます。（Figure 15.4）
  • ここでは、ひとつのSEGREGATED CORE、ひとつのGENERIC DOMAIN、脇役を担う2つのドメイン特化のパッケージに落ち着きました。より深い洞察により、Customerに対しGENERIC SUBDOMAINが作られたり、Customerが出荷に特化したものになるかもしれません。
  • 有用で意味のあるMODULESを認識することはモデリングの活動です（Chapter 5 で議論したように）。開発者とドメインエキスパートは、知識の咀嚼のプロセスの一環として戦略的な蒸留において協力します。

担当者のつぶやき †

みんなの突っ込み †


まとめ (議事録) †

Menu