ドメイン駆動設計 　Domain-Driven Design ( DDD )　 準備　／　スタートアップ　／　ブラッシュアップ　／　チャレンジ　／ 参考書籍　／

1. 有限会社 システム設計 増田 亨
ブログ： システム設計日記 (http://masuda220.jugem.jp/)
Twitter ： http://twitter.com/masuda220

2. DDD: Domain-Driven Design
ドメイン駆動設計
役に立つソフトウェアを
楽しく作る
ドメインモデル中心で

3. ドメインモデル？
ドメインモデル
利用者の関心ごとの模型
コード
com.systemsekkei.model .*
利用者の関心ごとの実装

4. ＤＤＤ こだわりポイント
ドメインモデル 利用者の関心ごとの模型
この設計・実装を開発の中心にする
原則：設計してからコード
設計駆動開発 もうひとつの DDD : Design-Driven Development
モデル駆動設計 MDD: Model-Driven Design
言葉と絵で、関心ごとの模型を作って、設計、実装
iterate(反復）
Evolve
increment(増分)
少しずつ、継続的に成長
continuous(絶え間なく）

5. いろいろあるよね xDD
テスト駆動開発(TDD)
ユースケース駆動開発(UCDD)
振舞い駆動開発(BDD)
チケット駆動開発(TiDD)
画面駆動開発(ScrDD?)
エクセル駆動開発(ExDD)？
リスク駆動・アーキテクチャ中心(RD/AC)

6. 華麗で楽しい？
シングル xDD

7. 悪路走破には、四輪駆動
マルチ xDD

8. より速く、より効率的に
８輪駆動
駆動力の分散配置
（８つのインホイールモータ&変速ギヤ）
８輪の協調動作
電気自動車エリーカ （センサーとシグナル同期）
ポルシェ９１１ターボを上回る加速性能
ポルシェの１０倍の燃費効率

9. ＤＤＤ的８輪駆動
ユース
テスト 振舞 ケース
駆動 ユーザ受入テスト重視 駆動 駆動
動きと構造の補完関係
画面
駆動 ドメイン ドメインモデル＝構造設計
重要な情報源
伝達手段 駆動 最大リスク：
エクセル
駆動 利用者の関心ごとの理解不足
ドメインモデルの
作成、改良チケット先行
リスク アーキテクチャの
チケット 駆動 中核を
駆動 ドメイン層に

10. ドメイン駆動設計を実践すると
利用者の要求の
キャッチ力が高まり
利用者の関心ごとの
構造が見えてきて
要件の
追加や変更が
簡単で安全になる

11. DDDはソフトウェア設計
 設計原則：関心の分離
 SRP : 単一責任原則
 カプセル化、情報隠蔽 設計原則を
 モジュール化（凝集）
．．．
ドメインモデルの
設計・実装で実践する
 設計原則：協調
 疎結合：必要最小限の結合関係
 モジュール化（公開インタフェースの最小化）
．．．

12. 基本パターン： Whole-Part
（関心の分離）＋（協調）の基本パターン
繰り返し、適用シーンがでてくる、基本中の基本パターン
利用者に有用で、かつ、最もシンプルなインタフェースは？
全体 どんな部品を、どんな構造でまとめるか？
部品群を、どうコントロールするか？
もっと部品に委譲できないか？
それぞれの部品の役割は？
部品Ａ 部品Ｎ ・関心ごとの分離
．．．
・単一責任原則

13. 準備とトライアル

14. DDD 実践シナリオ
利用者の関心ごとの置き場所を作る
利用者の関心ごとを見つける
利用者の関心ごとをコードにしてみる
利用者の関心ごとの妥当性を検証する
利用者の関心ごとの改善点を発見する

15. 関心の分離（１）
画面 UIコントローラ ＤＢアクセス
メール送信
メッセージング

16. 置き場所の追加
画面 UIコントローラ ＤＢアクセス
メール送信
利用者の関心ごと
を記述する場所
メッセージング

17. 依存関係
画面 UIコントローラ ＤＢアクセス
利用する
利用する 利用する
利用する
メール送信
利用者の関心ごとを 利用する
記述するクラス群 メッセージング
誰から使われているか知らない

18. 利用者の関心ごとクラス
画面 UIコントローラ 実装する ＤＢアクセス
呼び出す 顧客リポジトリ
<< interface >>
顧客登録サービス 登録する() : void
<< application controller >> 利用する 存在を確認(顧客) : Boolean
利用する 利用する
メール送信
顧客 顧客トランスファー 実装する
<< interface >>
<< domain object >>
Thank Youメール送る(顧客) : void
連絡方法 実装する
関係部門に通知する(顧客) :void
通知先() : メールアドレス
メッセージング

19. 私たちが使っている実装技術
画面 UIコントローラ
Velocity Ｓｐｒｉｎｇ Web Flow
テンプレート
Ｓｐｒｉｎｇ MVC
Ｓｐｒｉｎｇ Bind
Bean Validation
Ｓｐｒｉｎｇ ORM ＤＢアクセス
MyBatis SQLマップ
顧客 Ｓｐｒｉｎｇ Mail メール送信
<< domain object >>
Apache James
連絡方法
通知先() : メールアドレス
Ｓｐｒｉｎｇ JMS メッセージング
ActiveMQ
Mule ESB

20. ＤＤＤ 最初の一歩
とりあえず置き場所を作って、そこにドメインクラスを作って、
UIクラスやコントローラクラスから利用してみる
パッケージ com.clientname.applicationname.model をつくる
業務データの入れ物を、最低ひとつ、追加する --- Customer.java
業務ロジックメソッドを、最低一つ、追加する --- MailAddress contactTo()
顧客の言葉／業務要件を ごちゃごちゃしてくるので
手掛かりに 整理整頓
繰り返す ・サブパッケージ追加 ・名前の変更
・クラス追加 ・クラスの移動
・フィールド追加 ・フィールドの移動
・メソッド追加 ・メソッドの移動

21. スタートアップ
まずは、やってみる
つまづく
本を漁る 対象業務のハンドブックや入門書
英語本は、ドメインモデルの
試してみる
・パッケージ名
・クラス名
・メソッド名
の宝庫
工夫してみる

22. リファクタリング （設計の改善）

23. 「業務の関心ごと」の分離
 業務知識が 注文
注文入力
ＵＩのコードに埋もれている 画面オブジェクト 顧客名
 画面オブジェクトから データ 注文金額
業務の関心ごと情報を抽出 合計()
 コントローラから、
業務ロジックを抽出 submit() { }
注文明細
金額計算()
 業務ロジックを、 商品
ドメインオブジェクトに移動 数量
単価
金額
業務の関心ごとだけ取り出して、別クラスにする 金額()

24. 手続型の設計（手続＋データ）を
ドメインオブジェクトにリフォーム
Order 注文
注文
Calculator
顧客名
顧客名
注文金額
合計() 注文金額
税額算出() 合計()
税額()
注文明細
商品 注文明細
数量
単価 商品
金額 数量
単価
金額
業務のロジックは、情報の近く に移動する
金額()
業務データと業務ルールをまとめる 税額()

25. 条件記述から業務ロジックを抽出
宿泊予約
宿泊予約
料金（）
料金（） is夏季()
夏料金()
冬料金()
If ( date.before( SUMMER_START ) If ( isSummer( date ) )
|| date.after( SUMMER_END ) ) {
{ charge = summerCharge() ;
charge = quantity * winterRate + winterFee ; }
} else
else {
{ charge = winterCharge()
charge = quantity * summerRate ; }
}
クラス設計に業務の記述を増やす

26. コレクションのカプセル化
技術的な関心 → 業務の関心
顧客 顧客
List<注文> 購買履歴
setList（） 履歴に追加（注文）
getList() 最後の注文()
平均購買額（）
List<Order> orderHistory =
List<Order> orderHistory ; new ArrayList<Order>();
void setHistory( List<Order>) void record( Order )
Order getLastOrder()
List<Order> getHistory() Amount totalPurchase()
業務でやりたいことをメソッドで表現

27. 単なる値を
ドメインオブジェクトに昇格する
注文 注文 顧客
String 顧客 氏名
連絡先
class Order
class Order {
{ Customer customer ;
String customer; }
}
class Customer
{
String name ;
}
業務の重要な関心ごと（顧客）を記述する入れ物を作る

28. 設計のヒント、パターンの利用

29. ドメインモデル設計パターン
 業務ドメインによく出てくる設計パターン
 用語や概念
 何が関心ごとか？
 どう設計するか？
 パターン集の目次
 さまざまな関心ごとを俯瞰する全体マップ
 パターン＝設計のヒント
 関心の分離のしかた
 協調のさせ方

30. 参考書籍
masuda220 リストマニア「ドメインモデル設計パターン」@アマゾン
 ドメイン駆動設計 by Evans まえがき、第１部
 ビジネスパターンによるモデル駆動設計 by Hruby
２章 構造パターン、５章 振舞パターン
 アナリシスパターン by Fowler A.1.5 基本型
 PoEAA by Fowler はじめに、２章 ドメインロジックの選択
 リファクタリング by Fowler ３章 変更の発散、変更の分散
 ストリームラインオブジェクトモデリング by ニコラ
３章 協調パターン
 UML によるビジネスモデリング by エリクソン
５章ビジネスルール
 The Data Model Resource Book 1,2,3
 Data Model Patterns by Hay

31. Value Object
 基本語彙の設計・実装パターン
 String, BigDecimal, Date/long のラッパー
 型宣言 -> 表現力の向上
 氏名、社名、…
 金額、数量、日数、…
 登録日、締切日、…
 不変 -> 振舞の安定
 パラメータ付コンストラクタで生成
 set メソッド禁止
 演算結果は、新たにオブジェクトを生成して返す
 String と同じ

32. ６つの役割で考える
オブジェクトデザイン by ワーフスブラック
外部への見せ方
<<interface>>
部品群の構造化
全体 <<structurer>>
制御役 調整役
<<controller>> <<coordinator>>
If/for を 持つ／持たない の違い
情報保持
部品Ａ 部品Ｎ <<information holder>>
サービス（演算）提供
<<service provider>>

33. 識別にフォーカスしたクラス
 識別番号（参照番号）
 発番方法
 一意性確保／検証
 認証
 番号と実体の照合方法、記録
 識別名
 氏名、品名、…
 一意でなくても良い。人間にとっての判断材料。
 DDD Entity パターン

34. 手順やルールをクラスにまとめる
 Procedure クラス
 業務の手順
 コンピューティング手順
 状態を持たない
 Policy クラス
 オーバーブッキングポリシー
 キャンセルポリシー
 状態を持たない
 Rule クラス
 Policy クラスの部品

35. 集約、モジュール、リポジトリ
 いつもいっしょに扱う単位
全体  例：注文ヘッダーと明細
 例：顧客Entityと連絡先
 パッケージ宣言でモジュール化
 全体クラス Publicで公開
 部品クラス デフォルトで隠蔽
 リポジトリで一体操作
部品Ａ 部品Ｎ  格納する塊（ヘッダと明細）
 取り出す塊

36. その他の参考パターン（１）
 グルーピング、関連づけ、構造化
 「一覧」 <---- List クラスのラッパー
 分類（クラス分け、カテゴリー）
 グループ ／メンバー 、コンテナ／コンテンツ、アセンブリ／パーツ
 セット（商品）、パッケージ(販売), オプション・アダプタ・アクセサリ…
 予定、約束
 スケジュール
 契約
 通知、連絡、申し送り
 責任・権限
 部門、役割、ポスト
 承認ルート
 兼任

37. その他の参考パターン（２）
 照合
 多対多の解決
 例：売上計上、締と請求、入金消込
 日付
 予定日、残日数、期限切れ
 期間、間隔
 日付演算
 金額・数量
 単位換算
 数値演算と精度
 場所
 識別方法
 経度緯度、郵便番号、都道府県・市区町村、番地、最寄駅、沿線、…
 包含関係

38. その他の参考パターン（３）
 ドメインモデル内の階層化 （関心ごとの分離）
 意思決定層
 ポリシー、プロシージャ層
 オペレーション層
 イベント：注文、入出庫、…
 ステート：残高、〇〇中,△△待ち、 …
 リソース（商品、場所、… )層

39. チャレンジテーマ
1. 隣接ドメインと領域の重なり
2. 状態遷移とコミュニケーション
3. イベントソーシング
4. 基本構造の複雑化
5. 時系列変化

40. 隣接ドメインと領域の重なり
 同じもの？
 発注／受注／注文
 見込み客、顧客、契約者、出荷先、請求先、…
 作り方は？
 中核部分を共有して密結合？
 支援部分を部品として共有？
 別々に作って、疎結合？
 別々に発展させる vs. 寄せていく

41. 状態遷移
 業務ルールの宝庫
 修正可否、取消手順、アラート、締切、督促、…
 モデリングテクニック
 状態機械 （イベント・ステートモデル）
 状態遷移表
 論理的に記述・検証でき、実装も安定する。
 利用者（業務専門家）の用語（メンタルモデル）とのギャップ
 「状態」「○○中」「△△待ち」, …
 言葉の意味がそもそも違う？ (状態機械ではない？）
 コミュニケーションのハードル
 モデルの間違いの発見の遅れ
 テストの自動化

42. イベントソーシング
 ビジネスプロセス＝イベント駆動
 イベントソーシング
 元データは、イベントの発生記録（伝票）
 ステート（残高や状態、帳簿）は、派生（再構築可能）
 非同期メッセージング
 ドメイン駆動アーキテクチャの実装技術
 業務モデルと親和性が高い（はず）
 ＤＢアプリケーション(OLTP)が先行したが、今後の有望分野
 課題
 モデリング （非同期、並行処理、エラー処理、リトライ、同期ポイント）
 設計 （特に、イベントハンドラの変更容易性）
 実装
 テスト （特にテスト自動化）

43. 扱う情報の構造の複雑化
 かつては、単純で、固定ロジックで対応できた
 リスト構造 （線形、連番、順序処理）
 単純なツリー構造 （大中小３分類、…）
 より複雑な構造への要求・期待
 マトリクス、キューブ、 ファセット、… ( 多軸の分類整理 ）
 ネットワーク構造 （関係付けが、縦横無尽）
 よりアナログ（＝人間感覚）に近づける
 あいまい／関係づけ／重みづけの検索や判断
 Fuzzy 「らしさ」「感覚値」のデータ化と処理ロジック

44. 時系列の変化
変更履歴、追跡、復元、
予定、推定、…
 異動、組織変更、合併・分社化、…
 価格改定、価格変動
 評価額、為替レート、…
 予定・実績・差異
 先物、リスク管理、タイミング管理、…

45. ありがとうございました。