DDD
"Decision Support" Responsibilities (p.455) †
担当:中村
要約 †
"Decision Support" Responsibilities（意思決定サポートの責務） †
- Decision Supportのレイヤは計画や意思決定のためのツールを提供します。
- Routerは、Cargoを配送する最適な方法を選択するためのSERVICEであるため、Decision Support（意思決定サポート）に配置されます。
- これで、モデルは、Capability、Operations、Decision Supportの3つにレイヤ化されました。しかし、優遇された輸送を行うためにRouterにバイアスをかけるTransport Legの「is preferred」属性が調和を乱しています。この属性は、Transport Legが属している能力（Capability）のレイヤとは無関係であり、意思決定を方向付けるポリシーです。したがって、モデルは次のようにリファクタリングされるべきです。（Figure 16.7）（Figure 16.8）
- このリファクタリングは、Route Bias Policyをより明確にし、Transport Legを輸送能力の基本的な概念に集中させています。
- この新しいモデルは、いまや、スムーズに大規模な構造に順応します。
- そして、特定のレイヤに慣れた開発者は、部品の役割や依存関係を簡単に識別できます。
- UMLにてレイヤを線で区切りましたが、これはコミュニケーションをしやすくするためで、UMLの正式な記法ではないことに注意してください。
How Dose This Structure Affect Ongoing Design? （この構造は進行中の設計にどのように影響するのか？） †
- 大規模な構造を一度採用したら、その後のモデリングや設計に関する決定はそれを考慮して行わなければいけません。例として、有害物質の貨物について経路指定を制限するという新しい機能をすでにレイヤ化された設計に追加することを考えましょう。
- 設計の一例として、Cargoに経路指定のルールを連携する責務を追加するというものがあります。（Figure 16.9）（Figure 16.10）
- 問題は、Cargo（Operationsに属する）がHazMat? Route Policy Service（Decision Supportに属する）に依存する（逆向きの依存関係が発生してしまっている）ということです。
- 大規模な構造のルール（RESPONSIBILITY LAYERSのルール）に従うよう、CargoではなくRouterに経路指定のポリシーを使用する責務を割り当ててみましょう。（Figure 16.11）（Figure 16.12）
- これは、最初（Figure 16.9 や 16.10）のものよりも必ずしも良い設計とは言えませんが、プロジェクトの全員が一貫した方法で意思決定すれば、全体としての設計はよりわかりやすくなります。
- もし、大規模な構造によって扱いにくい設計上の選択を強制されてしまうのならば、EVOLVING ORDERに従いつつ、評価しできれば修正（必要なら破棄さえ）すべきです。
担当者のつぶやき †
振り返りのTryに従って、かなり要約してみました。
みんなの突っ込み †
