ドメイン駆動設計の実践 Part3 DDD

業務の言葉で開発を駆動していく

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

ドメイン駆動設計とは何か？
 「エリック・エヴァンスのドメイン駆動設計」
 Eric Evans “Domain-Driven Design” (DDD)
 できるソフトウェア開発者たちは、３０年以上
も前から、問題領域の理解が、ソフトウェア
開発の「肝」であることを知っていた。
 そのノウハウや考え方を集めて、「ドメイン駆
動設計(DDD)」という名前を付けてみた。

ドメイン駆動設計でない開発
 業務モデルとソフトウエアの実装が捻じれて
歪んでいる
 ソフトウェアの実装が
 業務の知識をまちがって記述
 業務の関心事より、技術の関心事を記述
 その結果、業務のごく自然な変更要求が
 既存のコードへの不自然・不合理・無理難題になる
 変更すると、おもわぬところに副作用が発生する
 そのソフトウェアは動いているが、正しくない。

捻じれて歪む構図
プレゼン資料
エクセル
画面イメージ

動くソフトウェア

ちんぷん
かんぷん
わからないまま
エクセルなんかがんばる
参考システムスクリーンショットソースコード
仕様 DDL
Java
XML
…
動いているが正しくないソフトウェアの完成

処方箋：ドメイン駆動設計
 業務の知識だけを記述したクラス群を、まず設計・実装する
それをソフトウェアの基盤に配置する
 ドメインモデルパターン
 PoEAA : Pattern Of Enterprise Application Architecture

 業務の用語が、そのまま、クラス名とメソッド名になる
 業務の単位が、そのままパッケージ名になる
 業務モデリングとドメインモデルの設計を常に一致させる
 分析開始＝ドメインモデル設計開始
 分析モデル＝ドメインモデル（粒度、構造、命名）
 関係者は、業務の言葉でコミュニケーションする
 分析に開発者も最初から参加（ドメインモデルの設計開始）
 ドメインモデルのレビューに業務エキスパートが参加
 コミュニケーションの語彙は「業務の用語」
 記法は、ＵＭＬ（形式的かつ視覚的な言語）

ドメイン駆動設計の効果
 うまく設計したドメインモデルを中核にしたシステ
ムは、ソフトウェアの変更を、劇的に、簡単に、安
全にする
 業務の知識を正しく反映した記述、構造
 変更箇所の特定が楽で、副作用の心配が少ない
 変更（＝ソフトウェアを育て続ける）が重要な関心事でないな
ら．．．
 ドメイン駆動設計は、余計な時間と手間がかかるので、やめたほ
うが良いかも。
 単発の受託開発プロジェクトには向かないかも。
 私たちは、ビジネスの発展とともに、継続的にソフトウェアを育て
ていくことにこだわっている。（同じ顧客、同じ問題領域）

DDD を現場で実践するために

やってみせ、言って聞かせて、さ
せてみせ、ほめてやる
 業務のモデリングがそのままソフトウエアのコードになって
いく過程をやってみせる
 技術的な味付けで「業務モデル」の大切さを説く
 Domain-Driven Design
 アメリカの著名な技術者たちが絶賛している

 Spring などメジャーなフレームワークが、DDD を指向して
いるので、それらを積極導入
 エクセルやワードではなく、UML でドメイン層を設計させ
てみる
 コード以外の論理表現の手段に目覚めてもらう
 コードのレビューで、業務の用語の理解度をチェック

ドメインモデル中心に作る
<<use>>
web.jar
ビューと
コントロール

<<use>>

業務の知識
ソフトウエアの核心
<<use>> 業務機能
application-service.jar （ファサード）
domain-model.jar
<<use>>

<<use>>
repository.jar データベースアクセス

ソフトウェア全体が、業務のモデルを反映した構造になる。

イベント・ソーシング
 「記録」と「通知」が業務の二大関心事
 業務イベントが発生したら、データベースに記録
 業務イベントが発生したら、しかるべきところに通知
 技術方式も、これを反映する
 データベース
 業務イベントをデータベースに Insert オンリーで記録
 「状態」は、上記のイベント記録時に更新 (トリガー）
 「入庫・出庫」記録が「正」。「在庫数」は「派生データ」
 非同期メッセージング
 業務イベントが発生したら、非同期でメッセージ送信
 データベースのトリガー＋ Mule ESB のデータベースポーリング
 ＲＥＳＴスタイル API
 バッチ処理の激減

 「予定／約束」と「リマインド／アラート」
 一定期日までに、起こすべき業務イベント（予定／約束）を記録
 直前にリマインドイベントを生成して、通知
 期限切れは、アラートイベントを生成して、通知

コードではなく、モデルで議論
 ドメインモデル設計の関心事(業務の言葉が登場する場所）
 パッケージ名
 パッケージ間の依存関係
 クラス名
 クラス間の関連
 メソッド名
 オブジェクトの特定方法（業務での識別方法/体系）
 クラス図（パッケージ図）がわかりやすい
 コードはノイズが多い
 依存関係や関連は、コードから読めない
 コードでは全体を俯瞰できない
 ドメインモデルのクラス図とコードは、常に一致させる
 モデルを変更したらコードを変更する
 コードを変更したらモデルを変更する

ドメインモデル設計の情報源
 ドメインエキスパートとの対話
 とってもたいへん
 こっちがあまりにも、業務を知らなすぎる
 エキスパートの頭の中を見ることはできない
 基本用語は、仕込んでおく（ドメインクラス候補）
 企業のホームページ
 問題領域の解説本（初心者向け）
 問題領域の解説本（英語→命名の元ネタ）
 既存システムの画面、実データ
 問題領域の基本構造
 解説本の章立て → パッケージ構造
ドメインモデルの設計パターン Google 検索

ドメインモデリング中心に進める
要件分析・要件定義ＲＤＲＡ（リレーションシップ駆動要件定義）
ユースケースごとに開発
システム価値システム境界システム
システム外部環境 (ＩCONIX)
ユースケース画面・帳表
業務フロー図ロバストネス図
コンテキスト図要求図予備設計

イベントプロトコル
利用シーン記述

詳細設計

ドメインモデル属性追加シーケンス図

基盤クラス追加

初期概念モデル Java
操作追加
概念モデルの洗練ソースコー
パッケージ構造ド
中核クラス関連クラス
依存クラスデータモデル DDL/SQL
ソースコー
クラスとテーブルの設計・実装ド

業務の知識をコードに反映する

「業務の関心事」の分離
 業務知識がＵＩのコードに埋注文注文
もれている入力画面
オブジェクト顧客名
 画面定義(View)から業務の注文金額
関心事を抽出する合計()
 コントローラから、業務ロジッ
クをメソッドに抽出 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 ;
}
業務の重要な関心事（顧客）を記述する入れ物ができた

業務モデルの粒度・構造と、クラスの設計を一致させる

ゴールド会員の登録
 一般会員が一定の条件をクリア
 購買実績
 支払事故なし
 承認手続きが必要

<<façade>>
ゴールド会員登録サービス
ゴールド会員登録 Service
<<entity>> 購入履歴
すべて情報会員
会員リポジトリ
会員番号
すべての操作氏名支払記録

http 依存の
関心事の分離
<<service>>
view定義と購買額が多くゴールド会員認定ポリシー変更が簡単で安全になる
control 支払事故がないソフトウェアを育てやすい
を抽出 <<value>>
<<entity>>
与信限度額ゴールド会員
ゴールド会員
ＤＢファクトリ
アクセス会員番号 <<value>>
を抽出氏名有効期限

承認が必要 <<service>>
ドメイン層のゴールド会員認定手続き
いろんなトランザクション <<transfer>>
ロジック承認依頼
スクリプト？ゴールド会員リポジトリ

実装は必要。重要なのは、設計。
ドメイン層以外も必要。重要なのは、ドメイン層。

ドメイン駆動設計の実践 Part3 DDD

Recommended

More Related Content

What's hot (20)

Similar to ドメイン駆動設計の実践 Part3 DDD (20)

More from 増田亨 (20)