DDD / Choosing Appropriate Layers

DDD

担当：佐藤匡剛

Choosing Appropriate Layers (p.460-464) †

要約 †

p.460 (Finding good RESPONSIBILITY LAYERS, or ...) †

• 良いRESPONSIBILITY LAYERSや他の大規模構造を見つけるのは、問題ドメインを理解し実験することと同じだ。ここでのガイドラインは、スクラッチ開発のときも、大規模構造を変更しようと思っているときも、同様に適用できる。

p.461 (As layers get switched out, merged, ...) †

• レイヤ構造を変えようとする際に、以下の性質は保持しておくとよい。
  • 物語（storytelling）。レイヤ構造は、ドメインの基本的な事実や優先度を語るべきもの。大規模構造の選定は、ビジネスモデリング以上に非テクニカルなもの。
  • 概念の依存関係（conceptual dependency）。「上位」レイヤの概念は「下位」レイヤの元に意味をなすべき。一方、下位レイヤの概念はそれ自体で独立しているべき。
  • CONCEPTUAL CONTOURS（概念の輪郭）。変化の頻度や原因が異なるオブジェクトは、別々のレイヤに分けるべき。

• レイヤ構造はいつも新たに考え直さなければいけないものではない。ある特定のドメインで共通して現れるレイヤ構造がいくつかある。

• 例えば、巨大な固定資産をもっているビジネス（工場、貨物船など）では、物流ソフトウェアは「ポテンシャル（別名：ケーパビリティ）」レイヤと「運用」レイヤで構成される。
  • ポテンシャル（potential） ･･･ 何をしようとしているかではなく、何ができるか？　組織のリソース（人含む）とリソースの構成され方がこのレイヤの中核。どのビジネスドメインにもあるが、特に運輸や製造で顕著なレイヤ。一時的な資産？（transient asset）もこのレイヤに含めるが、それが中心のビジネスなら、それを「ケーパビリティ（capability）」レイヤにする。
  • 運用（operation） ･･･ 日々、何をしているのか？　ポテンシャルレイヤ同様、リアルな現状を反映するレイヤ。ここでは、日々の労働や活動を把握する。運用側オブジェクトはポテンシャル側オブジェクトを元に作られるが、ポテンシャル側オブジェクトは自立している。

p.462 (In many, perhaps most, existing systems ...) †

• ほとんどのシステムは上記2つのレイヤでカバーできるだろう。しかし、日常業務の追跡を超えて、ユーザをガイドしたり意志決定を自動化したりする場合、「運用」よりも上のレイヤが必要になる。
  • 意志決定サポート（decision support） ･･･ どんなアクションを取るべきか、どんなポリシーを設定すべきか？　下位レイヤからの情報を元に、分析や意志決定をするためのレイヤ。
• 何もないところから意志決定することはできないので、「意志決定」ソフトウェアが下位レイヤに依存するのは当然。このレイヤは独自のBOUNDED CONTEXTを持ち、「運用」ソフトウェアとCUSTOMER/SUPPLIERの関係になる。レイヤ構造の利点は下位が上位に依存しないことなので、フェーズ毎の導入や古い運用システムの上に高レベルの拡張を行うことができる。

• 別のケースとして、ビジネスルールや法的要求を施行するソフトウェアのためのレイヤが考えられる。
  • ポリシー（policy） ･･･ ルールやゴールは何か？　ルールやゴールは受動的だが、他レイヤの振舞を制限するもの。「ポリシー」は下位レイヤのメソッド引数として渡されることもあれば、STRATEGYパターンで実現されることもある。「意志決定」レイヤは「ポリシー」のルールに基づき、そのゴールを達成する手段を提供する。

p.463 (Policy layers can be written in the ...) †

• 「ポリシー」レイヤは他のレイヤと同じ言語で実装してもいいし、ルールエンジンで実装してもいい。「ポリシー」はそれを適用するレイヤと別のBOUNDED CONTEXTにする必要はない。別BOUNDED CONTEXTにすると、別モデルになり複雑さが増してしまう。

• すべてのビジネスが工場や設備のケーパビリティに依存している訳ではない。金融、保険業では、「ポテンシャル」の大部分は日常の「運用」から決まる。「ポテンシャル」は「運用」と併合され、新しいレイヤになるかもしれない。
• よく登場するのは、顧客に対するコミットだ。
  • コミット（commitment） ･･･ 何を約束したか？　ゴールを示す「ポリシー」と、日常業務で直接発生する「運用」の両方の性質をもつもの。

p.464 (The Potential and Commitment layers are ...) †

• 「ポテンシャル」と「コミット」は相互排他ではない。両方を使うビジネスもある。必要なら他のレイヤを用いてもいい。しかし、レイヤ構造はシンプルにするのがベストだ。レイヤ数が4〜5を超えるなら、やり過ぎだ。レイヤが多すぎるとストーリーが不明になり、大規模構造のパターンが本来解決するはずの問題を解決できていない。
• これまで紹介した5つのレイヤは、一般的なRESPONSIBILITY LAYERSのセットになるかもしれないが、適用できるドメインもあればできないドメインもあるだろう。新しいドメインでは、全くオリジナルなレイヤ構造を考える必要があるかもしれない。自分の直観を信じろ、そしてEVOLVING ORDERに従え。

担当者のつぶやき †

• "transient asset"（p.462）がよく分からない。流動資産ではないよね？
• "reserve limit"（p.464）もよく分からない。

みんなの突っ込み †

まとめ (議事録) †