#devlove0409 講演資料 DDD Domain-Driven Design 「ソフトウェア開発でもっとも重要な仕事はドメインモデルの設計である」

1. こんな考え方で、
こんなやり方で、
取り組んでいます
有限会社 システム設計 増田 亨
ブログ： システム設計日記 (http://masuda220.jugem.jp/)
Twitter ： http://twitter.com/masuda220

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

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

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

5. 捻じれて歪む構図
プレゼン資料
エクセル
画面イメージ
動くソフトウェア
ちんぷん
かんぷん
わからないまま
エクセル なんかがんばる
参考システム スクリーンショット ソースコード
仕様 DDL
Java
XML
…
動いているが正しくないソフトウェアの完成

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

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

8. ドメインモデル中心に作る
<<use>>
web.jar
ビューと
コントロール
<<use>>
<<use>> 業務機能
（ファサード）
domain-model.jar application-service.jar
ソフトウエアの核心
<<use>>
<<use>>
repository.jar データベースアクセス
ドメイン層の設計・実装がいつも先

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

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

11. ドメインモデリング中心に進める
要件分析・要件定義
ユースケースごとに開発
システム価値 システム境界 システム
システム外部環境 (ＩCONIX)
ユースケース 画面・帳表
業務フロー図 ロバストネス図
コンテキスト図 要求図 予備設計
イベント プロトコル
利用シーン記述
詳細設計
ドメインモデル 属性追加 シーケンス図
基盤クラス追加
初期概念モデル Java
操作追加
概念モデルの洗練 ソースコー
パッケージ構造 ド
中核クラス 関連クラス
依存クラス データモデル DDL/SQL
ソースコー
クラスとテーブルの設計・実装 ド

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

13. プレゼンテーションとドメインの分離
 画面(View)からドメインオブ 注文 注文
ジェクト（Model)を抽出する 入力画面
オブジェクト 顧客名
 コントローラから、ドメインロ 注文金額
ジックをメソッドに抽出 合計()
 コントローラからドメインロジッ
クのメソッドを、ドメインオブ submit() { }
注文明細
ジェクトに移動 金額計算()
商品
数量
単価
金額
ドメインの関心事だけ取り出して、別クラスにする 金額()

14. 手続き的な設計からオブジェクトへ
Order 注文
注文
Calculator
顧客名
顧客名
注文金額
合計() 注文金額
税額算出() 合計()
税額()
注文明細
商品 注文明細
数量
単価 商品
金額 数量
単価
金額
金額()
操作を、関連する情報の近くに移動する 税額()

15. 条件記述からメソッドを抽出
宿泊予約
宿泊予約
料金（）
料金（） 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 ; }
}
ドメインリッチなクラスに成長

16. コレクションのカプセル化
顧客 顧客
購買履歴 購買履歴
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()
ドメインリッチなクラスに成長

17. 値をオブジェクトに置き換える
注文 注文 顧客
String 顧客 氏名
class Order
class Order {
{ Customer customer ;
String customer; }
}
class Customer
{
String name ;
}
ドメイン知識の入れ物の準備

19. <<façade>>
ゴールド会員登録サービス
ゴールド会員登録 Service
<<entity>> 購入履歴
すべて情報 会員
会員リポジトリ
会員番号
すべての操作 氏名 支払記録
http 依存の
関心事の分離
<<service>>
view定義と 購買額が多く ゴールド会員認定ポリシー 変更が簡単で安全になる
control 支払事故がない ソフトウェアを育てやすい
を抽出 <<value>>
<<entity>>
与信限度額 ゴールド会員
ゴールド会員
ＤＢ ファクトリ
アクセス 会員番号 <<value>>
を抽出 氏名 有効期限
承認が必要 <<service>>
ドメイン層の ゴールド会員認定手続き
いろんな トランザクション <<transport>>
ロジック 承認依頼
スクリプト？ ゴールド会員リポジトリ