ドメイン駆動設計(DDD)の実践Part2

こんな考え方で、
こんなやり方で、
取り組んでいます

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

ドメイン駆動設計とは何か？
 ソフトウェア開発のもっとも重要な仕事は、
ドメインモデルの設計である。
 ドメイン層以外も必要。
 Web 層( ビューとコントロール）
 データアクセス層
 ．．．
 重要なのは、ドメイン層
 「実装」は必要。
 重要なのは設計

なぜ、ドメイン駆動設計か？
 うまく設計したドメインモデルを中核にしたシス
テムは、ソフトウェアの変更を、劇的に、簡単
に、安全にするから
 変更（＝ソフトウェアを育て続ける）が重要な関心事でな
いなら．．．
 ドメイン駆動設計は、余計な時間と手間がかかるので、や
めたほうが良いかも。
 単発の受託開発プロジェクトには向かないかも。
 私たちは、継続的にソフトウェアを育てていくことにこだわっ
ている。（同じ顧客、同じ問題領域）

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

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

動くソフトウェア

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

ねじれの原因
 業務の関心事に、開発者が関心が無いから
 開発チームのメンバーは、依頼元の会社の事業について、興
味を持っていますか？
 この会社は、どんな顧客に、どんな価値を提供する？
 ライバル企業はどこ？
 競争相手との差別化ポイントは？
 開発中のソフトウェアは、その差別化ポイントを、どう強化する？
 業務の用語を、そのまま、クラス名やメソッド名にするのが良い
設計だと思っていますか？
 開発者同士で、話す時に、業務の言葉で、議論しています
か？

DDD を実際にやる
自分たちのやり方

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

<<use>>

<<use>> 業務機能
（ファサード）
domain-model.jar application-service.jar

ソフトウエアの核心
<<use>>

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

ドメイン層の設計・実装がいつも先

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

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

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

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

詳細設計

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

基盤クラス追加

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

いえいえ、
やる気があれば、
ドメイン駆動設計のネタはいっぱいあります

プレゼンテーションとドメインの分離
 画面(View)からドメインオブ注文注文
ジェクト（Model)を抽出する入力画面
オブジェクト顧客名
 コントローラから、ドメインロ注文金額
ジックをメソッドに抽出合計()
 コントローラからドメインロジッ
クのメソッドを、ドメインオブ 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 ; }
}
ドメインリッチなクラスに成長

コレクションのカプセル化
顧客顧客

購買履歴購買履歴

set購買履歴（）記録（注文）
get購買履歴() 最後の注文()
総購買額（）

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>>
ドメイン層のゴールド会員認定手続き
いろんなトランザクション <<transport>>
ロジック承認依頼
スクリプト？ゴールド会員リポジトリ

ドメイン駆動設計(DDD)の実践Part2

ドメイン駆動設計(DDD)の実践Part2

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

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

More from 増田亨

More from 増田亨 (20)

Recently uploaded

Recently uploaded (10)