新機能の導入 : 割り当てチェック (P181) †
要約 †
- 181-1 (Up to this point〜)
- 181-2 (The sales division 〜)
- 貨物船会社の営業部門は，顧客の管理や販売予測などのために別のシステムを使っています．その機能の一つは，特定の種類の積み荷をどれだけ割り当てできるかを管理することです．
- 182-2 (Now they want 〜)
- 顧客はこの機能が予約システムと統合され，予約が入る時はその割り当てが受け入れ可能かチェックすることを要望しています．
- 182-3 (The information needed 〜)
- 必要な情報は 2 カ所にあり，予約アプリケーションは要求された予約を受け入れるか拒否するかを販売管理システムに問い合わせなくてはなりません．情報の流れは図 7.9 のようになります．
- 図 7.9
二つのシステムを接続する †
- 182-4 (The Sales Management System 〜)
- 販売管理システムは，我々の心の中のモデルで書かれてはいません．もし予約アプリケーションが直接的に相互作用するなら，予約アプリケーションは販売管理システムの設計に適合させなくてはなりません．それは明確な MODEL-DRIVEN DESIGN を維持することを困難なものにし，UBIQUITOUS LANGUAGE を混乱させるでしょう．代わりに，我々のモデルから販売管理システムの言語に変換するクラスを作ります．このクラスは，第 14 章で議論する ANTICORRUPTION LAYER としての役割を果たします．
- 183-1 (This is an interface 〜)
- それを販売管理インタフェースと呼ぶのではなく，外部システムから得る必要がある機能を SERVICE として定義し，我々のシステムにおける責務を反映した名前を与えます．「Allocation Checker」
- 183-2 (If some other 〜)
- 販売管理システムインタフェースような低レベルのクラスは有用ですが，それは変換の責務を持たず，Allocation Checker の背後に隠されるので，ドメイン設計には現れません．
モデルを拡張する : ビジネスの分割 †
- 183-3 (Now that we have 〜)
- 「このタイプの Cargo はどれだけ予約できるか？」というインタフェースはどのように提供すべきでしょうか．我々のドメインモデルはまだ Cargo をカテゴライズしていません．販売管理システムでは，Cargoのタイプは単なる文字列の集合です．我々は，積み荷にはカテゴリがあるという知識に対応してドメインモデルを豊かにする必要があり，新しい概念を導入するためにドメインエキスパートとブレーンストーミングすべきです．
- (11 章で議論するように) 時々，アナリシスパターンはモデリングを解決するためのアイディアを与えてくれます．書籍「アナリシスパターン」は，この種の問題に対処するENTERPRISE SEGMENT (業務範囲) パターンを説明しています．
ENTERPRISE SEGMENT は業務をブレークダウンすることで定義された範囲の集合です．この概念を使うと，割り当てのモデルはより表現力豊かとなり，インタフェースはシンプルになります．Enterprise Segment と呼ばれるクラスは追加の VALUE OBJECT としてドメインモデルと設計の中に現れ，それは Cargo から得られなければなりません．
- 図 7.10
- 184-2 (The Allocation Checker will 〜)
- Application Checker は，Enterprise Segment と外部システムにおけるカテゴリ名とを変換します．Cargo Respository は Enterprise Segment に基づく問い合わせも提供しなければなりません．ごにょごにょ
- 184-3 (There are still 〜)
- この設計にはまだいくつか問題があります．
- 予約アプリケーションに，「その Enterprise Segment に，新しい Cargo と予約済みの数を足した数よりも多くのスペースが割り当てられているなら，Cargo は受け入れられる」というルールを適用することになりました．ドメインの責務としてこのビジネスルールを強制し，アプリケーション層で実行されないようにすべきです．
- 予約アプリケーションがどのように Enterprise Segment を取得するのか明確ではありません．
- 185-1 (Both of these responsibilities 〜)
- どちらも Application Checker の責務のように見えます．これらのインタフェースを 2 つの SERVICES に分割することで，インタラクションが明確で明示的になります．
- 図 7.11
- 185-2 (Teh only serious constraint 〜)
- この統合によって与えられる唯一の深刻な制約は，Allocation Checker が Enterprise Segment に変換できない状況で販売管理システムを使ってはならないということです (この設計では， Cargo Respository はEnterprise Segment を扱うように設計するだけでよく，販売管理システムの変更は Application Checker に小さな影響しかありません．Enterprise Segment は FACADE と考えられます)．
パフォーマンスチューニング †
- 185-3 (Although the Allocation Checker's 〜)
- ドメイン設計における Allocation Checker のインタフェースは以上ですが，内部実装でパフォーマンスの問題があれば解決する機会を与えます．選択肢の一つはキャッシュで，メッセージングのオーバーヘッドを減らします．
担当者のつぶやき †
みんなの突っ込み †
- これは・・・EvansによるAnalysis Patternsのプロモーションか何かなんでしょうか・・・ENTERPRISE SEGMENT自体のもう少し詳しい説明が欲しい所ですよね。 -- 和智?
