第4回福岡DDD勉強会 での発表資料です。 http://www.zusaar.com/event/5487007

1. エリック・エヴァンスの
ドメイン駆動設計
!
７章：言語を利用する：応用例
すごく、、、AKIMICYUです、、、

2. 第２部
モデル駆動設計の構成要素
第4章 ドメインを隔離する
第5章 ソフトウェアで表現されたモデル
第6章 ドメインオブジェクトのライフサイクル
第7章 言語を使用する：応用例 ここ

3. ７．言語を利用する：応用例
４∼６章：堅固なモデル駆動設計を維持するための
パターンランゲージを個々に紹介
でも、実際のプロジェクトではパターンは組み合
わせて使用される
７章では、入り組んだ例（複合例）を紹介
モデルと設計が改良されていく様子（モデル駆動
設計）を、段階を追いながら見ていく

4. 最初の要求
貨物輸送システム
1. 顧客貨物に対する主要な荷役を追跡する
2. あらかじめ貨物を予約する
3. 貨物が荷役の課程で所定の場所に到達した際、
自動的に請求書を顧客に送付する

5. 輸送ドメインのモデル
クラス図(図7.1)
ドメインに関する知識を体系化
チームに対して言語を提供 → ユビキタス言語
要件を、ユビキタス言語で記述(p.165近辺)

6. モデルの改良

7. モデルの改良(1/5)
ドメインを隔離する：アプリケーションの導入
レイヤ化アーキテクチャの適用
ユーザレベルのアプリケーション機能
1. 追跡問い合わせ
2. 予約アプリケーション
3. イベント記録アプリケーション

8. モデルの改良(2/5)
エンティティと値オブジェクトを区別する
エンティティ： 顧客、貨物、荷役イベント、配
送記録、位置、、、
値オブジェクト： 配送仕様
役割は、それによって限定される関連を説明する
が、履歴や連続性は持たない(値オブジェクト)

9. モデルの改良(3/5)
輸送ドメインの関連を設計する
双方向の関連は、設計上問題
関連を れる方向はドメインに付帯する洞察を
捉えていることが多く、モデル自体を深める
る方向が制限されている関連もある(図7.2)

10. モデルの改良(4/5)
集約の境界(図7.3)
顧客、位置、輸送機器移動：
独自の同一性＆多くの貨物から被共有 → それぞ
れ独自に集約を持ち、そのルートとなっていないと
いけない
貨物は？
明らかに集約ルート。境界を検討する必要あり

11. モデルの改良(5/5)
リポジトリを選択する
それぞれにリポジトリを用意、選ばれた集約ルー
トへのアクセスが与えられる(図7.4)
荷役イベントリポジトリは無し
配送記録との関連をコレクションとして実装
するための暫定処置？ → 後で。

12. シナリオのウォークスルー
と設計見直し

13. 決定のクロスチェック
常に段階を追って、シナリオを見ながら、アプリケーションの問
題を効果的に解決できることを確認
サンプルアプリケーションの機能（シナリオ）
貨物の荷出し地を変更する、リピーターへの対応、、、
オブジェクトの生成
貨物用のファクトリとコンストラクタ
荷役イベントへの追加には、配送記録への挿入が必要（図7.5）

14. 設計の見直し(1/2)
リファクタリングのために立ち止まる
モデリングと設計は、絶えず前進するだけのプロセスで
はない
頻繁にリファクタリングを行い、モデルと設計を改善す
る新しい洞察を活用しなければ、立ち往生する
配送記録が持つ荷役イベントのコレクションをクエリと
して実装することで、荷役イベントの挿入が単純になり、
貨物集約との競合がらも解放される(図7.6)

15. 設計の見直し(2/2)
輸送モデルにおけるモジュール
モジュール構成にモデルが影響をうける事例
「エンティティ/値オブジェクト/サービス」というモ
ジュールの切り方は、ドメインについての知識を伝え
ていない(図7.7)
「顧客/輸送/請求」という大まかなドメイン概念に基
づいたモジュール(図7.8) ← 素直な分割

16. 新機能を導入する：
配分チェック

17. 新機能：配分チェック
配分チェックの要件(新規追加, 図7.9)
特定のタイプの貨物をどれくらい予約するべきか
について配分可能にしてイールドマネジメント
収益の高い貨物を、それほどでもない貨物で一杯
になったために積み込めないという事態を防ぐ
過小予約や過度のオーバーブッキングを回避

18. 必要な対応(1)
２つのシステムを接続する(販売管理システムとの接続)
これまで取り組んできたものと同じモデルを念頭に書かれ
ていない（外部システム）
ユビキタス言語に混乱をきたさないよう、間に腐敗防止層
を設ける
名称を「配分チェックサービス」として、こちらのシステ
ムにおける責務を反映させる (×販売管理インタフェース)

19. 必要な対応(2)
モデルを強化する：ビジネスのセグメント化(図7.10)
「このタイプの貨物をどれくらい予約してもよいか？」という質問に答えるた
めには、どのようなインタフェースを提供すればよいだろうか？
やっかいなのは貨物の「タイプ」とは何かを定義すること
今回は、他のシステムのドメインを、こちら側の観点で抽象化し直す
ドメインモデルを豊かにして、貨物にカテゴリが存在するという知識に適
応できるようにする必要がある
エンタープライズセグメント：ビジネスの分割方法を定義した次元軸の集まり
ドメイン責務を配分チェックサービスに移す(図7.11)

20. 最後に
腐敗防止層やサービス、エンタープライズセグメン
トの使用によって、販売管理システムの機能を予約
システムへきれいに統合できた
エンタープライズセグメントを取得する責務を、な
ぜ貨物に持たないのか？
目的によって、モデルは異なる
ドメインの切り方の選択肢は多数