RESPONSIBILITY LAYERS (450ページ) †
要約 †
RESPONSIBILITY LAYERS(責任レイヤー)
本書を通して、個々のオブジェクトの責務は狭く小さく割り当ててきた。責任駆動設計はより大規模のものにも適用できる。
***
問題サマリ
- 個々のオブジェクトが自分自身で責務を決めているのならば、ガイドラインも統一性もなく、広範なドメイン領域を同時に取り扱うことはできない。大きなモデルに凝集性(coherence)を与えるためには、責務の割り当てに構造を課すと良い。
[問題の解決方法についての説明]
- ドメインの中には自然な層(stratification)が存在するドメインもある。ある概念や活動は単独だったり様々な理由で色々な速度で変化する他の要素のバックグラウンドとして起こる。この層(stratification)はをもっとも成功したアーキテクチャデザインパターンであるレイヤー化(layering: POSA本等)を意味している。
- レイヤー(Layers)とはシステムの区画(partition)である。それぞれの区画の要素は下のレイヤーを知っていて利用することができるが、上の階層のことは知らず、依存することもない。
- このようなアドホックなレイヤー化は依存性のトレースを簡単にし、直感的にするが、モデルへの深い洞察やモデリングのガイドラインは得られない。もっと意図的な何かが必要だ。
- 自然な層があるモデルでは、概念的なレイヤーが主要責務とともに定義される。その際、レイヤー化と責任駆動設計の二つの重要な原則が統一される。
- 概念的なレイヤーの責務は個々のオブジェクトの責務よりより広いに違いない。MODULESやAGGREGATESの設計と同様に、概念的なレイヤーは主要な一つの責務の領域に収まるように構成(factored)される。高レベルの責務とレイヤー化を結びつけることはシステムに体系的な原則をもたらす
Therefore:
- モデルの概念的な依存性を調べなさい。ドメイン各所の変化の源と変化具合を調査しなさい。自然な層を識別したのなら、広い抽象的な責務を与えなさい。これらの責務はシステムのハイレベルな目的とデザインを語るべきです。ドメインオブジェクトやAGGREGATE、MODULEのそれぞれの責務がきちんと一つのレイヤーの責務に合うように、モデルをリファクタリングしなさい。
抽象的な記述であるが、サンプルを通して明確にしたい。私は章の最初で説明した衛星通信シミュレータや、生産管理や財務管理のような多くのドメインでRESPONSIBILITY LAYERSは良い効果をもたらしていたきたのを見てきた。
***
Example 洞察: 輸送システムのレイヤー化 †
- チームメンバーはドメインにどっぷり漬かり、その概念の中に自然な層(stratification)に気づいた。積み荷(cargo)に言及することなく、輸送予定(船舶と列車の運行予定)を考えるのは道理にかなっている。概念上の依存性は明確だ。チームは早速、"Operations(業務)"とその下地となる"Capability(業務能力)"の二つのレイヤーを分けた。
"Operations"の責務
- 会社の過去/現在/計画中の活動はOperationsレイヤーに属する。
- Cargoは日常的な業務の中心を占める。
- Route Specificationは配送要件を示し、Cargoに不可欠である。
- Itineraryは配送計画(operational delivery plan)である。
- これらのオブジェクトはCargo AGGREGATEの構成要素である。
- ライフサイクルは配送の活動期間と密接に結びついている。
"Capability"の責務
- Capabilityレイヤーは会社がOperationsを遂行するのに必要なリソースの層である。
- Transit Legは本レイヤーの典型例である。船舶は航行予定と貨物運搬(運搬能力)をスケジュール化される。
- 船体の管理業務を考えるならばTransit LegはOperationsレイヤーに分類されるだろうが、今回はそこまで考ない。(必要ならば"Transport Operations"と"Cargo Operations"に分ける)
- 顧客は個人ではなく法人顧客向けの長期的な関係を考えているので、Customerは業務能力側(Capabilityレイヤー)に位置づけられる。これは技術的ではなくドメインの理解から決定である。
- CargoとCustomerの関連を一方向にすることは、設計の改善であるが、大規模構造制約が必要ならばこれは要件として扱わなければならない。
RouterはOperationsレイヤーにはそぐわない、次節では"Decision Support"レイヤーを考察する。
担当者のつぶやき †
- つたない理解ですが、モデリングの際にはレイヤー化を考慮すると良くて、それも漠然とではなくレイヤーの責務に注目するのがいい、という感じで理解しました。(ただレイヤー化しているなら自然とレイヤーの責務も考えないことはないような感じもしました)
- 細かいことですが、Figure 16.5のCargoとCustomerの関連の多重度は逆ですよね?
みんなの突っ込み †