ドメイン駆動設計 ( DDD ) をやってみよう

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

DDD: Domain-Driven Design
ドメイン駆動設計

役に立つソフトウェアを

楽しく作る

ドメインモデル中心で

ドメインモデル？
ドメインモデル
利用者の関心ごとの模型

コード

com.systemsekkei.model .*
利用者の関心ごとの実装

ＤＤＤこだわりポイント
ドメインモデル利用者の関心ごとの模型
この設計・実装を開発の中心にする

原則：設計してからコード
設計駆動開発もうひとつの DDD : Design-Driven Development

モデル駆動設計 MDD: Model-Driven Design
言葉と絵で、関心ごとの模型を作って、設計、実装

iterate(反復）
Evolve
increment(増分)
少しずつ、継続的に成長
continuous(絶え間なく）

いろいろあるよね xDD
テスト駆動開発(TDD)
ユースケース駆動開発(UCDD)
振舞い駆動開発(BDD)

チケット駆動開発(TiDD)
画面駆動開発(ScrDD?)
エクセル駆動開発(ExDD)？

リスク駆動・アーキテクチャ中心(RD/AC)

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

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

より速く、より効率的に
８輪駆動

駆動力の分散配置
（８つのインホイールモータ&変速ギヤ）

８輪の協調動作
電気自動車エリーカ（センサーとシグナル同期）

ポルシェ９１１ターボを上回る加速性能
ポルシェの１０倍の燃費効率

ＤＤＤ的８輪駆動
ユース
テスト振舞ケース
駆動ユーザ受入テスト重視駆動駆動
動きと構造の補完関係
画面
駆動ドメインドメインモデル＝構造設計

重要な情報源
伝達手段駆動最大リスク：
エクセル
駆動利用者の関心ごとの理解不足
ドメインモデルの
作成、改良チケット先行
リスクアーキテクチャの
チケット駆動中核を
駆動ドメイン層に

ドメイン駆動設計を実践すると
利用者の要求の
キャッチ力が高まり

利用者の関心ごとの
構造が見えてきて
要件の
追加や変更が
簡単で安全になる

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

基本パターン： Whole-Part
（関心の分離）＋（協調）の基本パターン
繰り返し、適用シーンがでてくる、基本中の基本パターン

利用者に有用で、かつ、最もシンプルなインタフェースは？

全体どんな部品を、どんな構造でまとめるか？
部品群を、どうコントロールするか？
もっと部品に委譲できないか？

それぞれの部品の役割は？
部品Ａ部品Ｎ・関心ごとの分離
．．．
・単一責任原則

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

関心の分離（１）
画面 UIコントローラＤＢアクセス

メール送信

メッセージング

置き場所の追加

メール送信
利用者の関心ごと
を記述する場所

依存関係
利用する
利用する利用する

利用する
メール送信

利用者の関心ごとを利用する

記述するクラス群メッセージング

誰から使われているか知らない

利用者の関心ごとクラス
画面 UIコントローラ実装するＤＢアクセス

呼び出す顧客リポジトリ
<< interface >>

顧客登録サービス登録する() : void
<< application controller >> 利用する存在を確認(顧客) : Boolean

利用する利用する
メール送信

顧客顧客トランスファー実装する
<< interface >>
<< domain object >>
Thank Youメール送る(顧客) : void
連絡方法実装する
関係部門に通知する(顧客) :void
通知先() : メールアドレス

私たちが使っている実装技術
画面 UIコントローラ
Velocity Ｓｐｒｉｎｇ Web Flow
テンプレート
Ｓｐｒｉｎｇ MVC
Ｓｐｒｉｎｇ Bind
Bean Validation
Ｓｐｒｉｎｇ ORM ＤＢアクセス
MyBatis SQLマップ

顧客Ｓｐｒｉｎｇ Mail メール送信
<< domain object >>
Apache James
連絡方法
通知先() : メールアドレス
Ｓｐｒｉｎｇ JMS メッセージング
ActiveMQ
Mule ESB

ＤＤＤ最初の一歩
とりあえず置き場所を作って、そこにドメインクラスを作って、
UIクラスやコントローラクラスから利用してみる

パッケージ com.clientname.applicationname.model をつくる

業務データの入れ物を、最低ひとつ、追加する --- Customer.java

業務ロジックメソッドを、最低一つ、追加する --- MailAddress contactTo()

顧客の言葉／業務要件をごちゃごちゃしてくるので
手掛かりに整理整頓

繰り返す・サブパッケージ追加・名前の変更
・クラス追加・クラスの移動
・フィールド追加・フィールドの移動
・メソッド追加・メソッドの移動

スタートアップ
まずは、やってみる
つまづく
本を漁る対象業務のハンドブックや入門書
英語本は、ドメインモデルの

試してみる
・パッケージ名
・クラス名
・メソッド名
の宝庫
工夫してみる

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

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

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

条件記述から業務ロジックを抽出
宿泊予約
宿泊予約
料金（）
料金（） 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 ; }
}
クラス設計に業務の記述を増やす

コレクションのカプセル化
技術的な関心 → 業務の関心
顧客顧客

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()

業務でやりたいことをメソッドで表現

単なる値を
ドメインオブジェクトに昇格する
注文注文顧客

String 顧客氏名
連絡先

class Order
class Order {
{ Customer customer ;
String customer; }
}
class Customer
{
String name ;
}
業務の重要な関心ごと（顧客）を記述する入れ物を作る

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

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

参考書籍
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

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

６つの役割で考える
オブジェクトデザイン by ワーフスブラック
外部への見せ方
<<interface>>
部品群の構造化
全体 <<structurer>>
制御役調整役
<<controller>> <<coordinator>>
If/for を持つ／持たないの違い

情報保持
部品Ａ部品Ｎ <<information holder>>

サービス（演算）提供
<<service provider>>

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

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

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

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

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

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

チャレンジテーマ

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

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

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

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

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

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

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

ドメイン駆動設計 ( DDD ) をやってみよう

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à ドメイン駆動設計 ( DDD ) をやってみよう

Similaire à ドメイン駆動設計 ( DDD ) をやってみよう (20)

Plus de 増田亨

Plus de 増田亨 (20)

Dernier

Dernier (9)