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

29,354 views

Published on

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

Published in: Technology
0 Comments
102 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
29,354
On SlideShare
0
From Embeds
0
Number of Embeds
2,514
Actions
Shares
0
Downloads
260
Comments
0
Likes
102
Embeds 0
No embeds

No notes for slide

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

  1. 1. 有限会社 システム設計 増田 亨ブログ: システム設計日記 (http://masuda220.jugem.jp/)Twitter : http://twitter.com/masuda220
  2. 2. DDD: Domain-Driven Designドメイン駆動設計 役に立つソフトウェアを 楽しく作る ドメインモデル中心で
  3. 3. ドメインモデル? ドメインモデル 利用者の関心ごとの模型 コード com.systemsekkei.model .* 利用者の関心ごとの実装
  4. 4. DDD こだわりポイントドメインモデル 利用者の関心ごとの模型 この設計・実装を開発の中心にする 原則:設計してからコード設計駆動開発 もうひとつの DDD : Design-Driven Developmentモデル駆動設計 MDD: Model-Driven Design 言葉と絵で、関心ごとの模型を作って、設計、実装 iterate(反復) Evolve increment(増分)少しずつ、継続的に成長 continuous(絶え間なく)
  5. 5. いろいろあるよね xDDテスト駆動開発(TDD) ユースケース駆動開発(UCDD) 振舞い駆動開発(BDD) チケット駆動開発(TiDD) 画面駆動開発(ScrDD?) エクセル駆動開発(ExDD)? リスク駆動・アーキテクチャ中心(RD/AC)
  6. 6. 華麗で楽しい?シングル xDD
  7. 7. 悪路走破には、四輪駆動マルチ xDD
  8. 8. より速く、より効率的に 8輪駆動 駆動力の分散配置 (8つのインホイールモータ&変速ギヤ) 8輪の協調動作電気自動車エリーカ (センサーとシグナル同期) ポルシェ911ターボを上回る加速性能 ポルシェの10倍の燃費効率
  9. 9. DDD的8輪駆動 ユース テスト 振舞 ケース 駆動 ユーザ受入テスト重視 駆動 駆動 動きと構造の補完関係画面駆動 ドメイン ドメインモデル=構造設計 重要な情報源 伝達手段 駆動 最大リスク:エクセル駆動 利用者の関心ごとの理解不足 ドメインモデルの 作成、改良チケット先行 リスク アーキテクチャの チケット 駆動 中核を 駆動 ドメイン層に
  10. 10. ドメイン駆動設計を実践すると 利用者の要求の キャッチ力が高まり 利用者の関心ごとの 構造が見えてきて 要件の 追加や変更が 簡単で安全になる
  11. 11. DDDはソフトウェア設計 設計原則:関心の分離  SRP : 単一責任原則  カプセル化、情報隠蔽 設計原則を  モジュール化(凝集) ... ドメインモデルの 設計・実装で実践する 設計原則:協調  疎結合:必要最小限の結合関係  モジュール化(公開インタフェースの最小化) ...
  12. 12. 基本パターン: Whole-Part (関心の分離)+(協調)の基本パターン 繰り返し、適用シーンがでてくる、基本中の基本パターン利用者に有用で、かつ、最もシンプルなインタフェースは? 全体 どんな部品を、どんな構造でまとめるか? 部品群を、どうコントロールするか? もっと部品に委譲できないか? それぞれの部品の役割は? 部品A 部品N ・関心ごとの分離 ... ・単一責任原則
  13. 13. 準備とトライアル
  14. 14. DDD 実践シナリオ利用者の関心ごとの置き場所を作る利用者の関心ごとを見つける利用者の関心ごとをコードにしてみる利用者の関心ごとの妥当性を検証する利用者の関心ごとの改善点を発見する
  15. 15. 関心の分離(1)画面 UIコントローラ DBアクセス メール送信 メッセージング
  16. 16. 置き場所の追加画面 UIコントローラ DBアクセス メール送信 利用者の関心ごと を記述する場所 メッセージング
  17. 17. 依存関係 画面 UIコントローラ DBアクセス 利用する利用する 利用する 利用する メール送信 利用者の関心ごとを 利用する 記述するクラス群 メッセージング 誰から使われているか知らない
  18. 18. 利用者の関心ごとクラス画面 UIコントローラ 実装する DBアクセス 呼び出す 顧客リポジトリ << interface >> 顧客登録サービス 登録する() : void << application controller >> 利用する 存在を確認(顧客) : Boolean 利用する 利用する メール送信 顧客 顧客トランスファー 実装する << interface >> << domain object >> Thank Youメール送る(顧客) : void連絡方法 実装する 関係部門に通知する(顧客) :void通知先() : メールアドレス メッセージング
  19. 19. 私たちが使っている実装技術 画面 UIコントローラVelocity Spring Web Flowテンプレート Spring MVC Spring Bind Bean Validation Spring ORM DBアクセス MyBatis SQLマップ 顧客 Spring Mail メール送信 << domain object >> Apache James 連絡方法 通知先() : メールアドレス Spring JMS メッセージング ActiveMQ Mule ESB
  20. 20. DDD 最初の一歩とりあえず置き場所を作って、そこにドメインクラスを作って、UIクラスやコントローラクラスから利用してみるパッケージ com.clientname.applicationname.model をつくる業務データの入れ物を、最低ひとつ、追加する --- Customer.java業務ロジックメソッドを、最低一つ、追加する --- MailAddress contactTo() 顧客の言葉/業務要件を ごちゃごちゃしてくるので 手掛かりに 整理整頓 繰り返す ・サブパッケージ追加 ・名前の変更 ・クラス追加 ・クラスの移動 ・フィールド追加 ・フィールドの移動 ・メソッド追加 ・メソッドの移動
  21. 21. スタートアップまずは、やってみるつまづく本を漁る 対象業務のハンドブックや入門書 英語本は、ドメインモデルの試してみる ・パッケージ名 ・クラス名 ・メソッド名 の宝庫工夫してみる
  22. 22. リファクタリング (設計の改善)
  23. 23. 「業務の関心ごと」の分離 業務知識が 注文 注文入力 UIのコードに埋もれている 画面オブジェクト 顧客名 画面オブジェクトから データ 注文金額 業務の関心ごと情報を抽出 合計() コントローラから、 業務ロジックを抽出 submit() { } 注文明細 金額計算() 業務ロジックを、 商品 ドメインオブジェクトに移動 数量 単価 金額 業務の関心ごとだけ取り出して、別クラスにする 金額()
  24. 24. 手続型の設計(手続+データ)をドメインオブジェクトにリフォーム Order 注文 注文Calculator 顧客名 顧客名 注文金額 合計() 注文金額 税額算出() 合計() 税額() 注文明細 商品 注文明細 数量 単価 商品 金額 数量 単価 金額業務のロジックは、情報の近く に移動する 金額()業務データと業務ルールをまとめる 税額()
  25. 25. 条件記述から業務ロジックを抽出 宿泊予約 宿泊予約 料金() 料金() is夏季() 夏料金() 冬料金()If ( date.before( SUMMER_START ) If ( isSummer( date ) ) || date.after( SUMMER_END ) ) {{ charge = summerCharge() ; charge = quantity * winterRate + winterFee ; }} elseelse {{ charge = winterCharge() charge = quantity * summerRate ; }} クラス設計に業務の記述を増やす
  26. 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. 27. 単なる値をドメインオブジェクトに昇格する 注文 注文 顧客String 顧客 氏名 連絡先 class Order class Order { { Customer customer ; String customer; } } class Customer { String name ; } 業務の重要な関心ごと(顧客)を記述する入れ物を作る
  28. 28. 設計のヒント、パターンの利用
  29. 29. ドメインモデル設計パターン 業務ドメインによく出てくる設計パターン  用語や概念  何が関心ごとか?  どう設計するか? パターン集の目次  さまざまな関心ごとを俯瞰する全体マップ パターン=設計のヒント  関心の分離のしかた  協調のさせ方
  30. 30. 参考書籍masuda220 リストマニア「ドメインモデル設計パターン」@アマゾン  ドメイン駆動設計 by Evans まえがき、第1部  ビジネスパターンによるモデル駆動設計 by Hruby 2章 構造パターン、5章 振舞パターン  アナリシスパターン by Fowler A.1.5 基本型  PoEAA by Fowler はじめに、2章 ドメインロジックの選択  リファクタリング by Fowler 3章 変更の発散、変更の分散  ストリームラインオブジェクトモデリング by ニコラ 3章 協調パターン  UML によるビジネスモデリング by エリクソン 5章ビジネスルール  The Data Model Resource Book 1,2,3  Data Model Patterns by Hay
  31. 31. Value Object 基本語彙の設計・実装パターン String, BigDecimal, Date/long のラッパー 型宣言 -> 表現力の向上  氏名、社名、…  金額、数量、日数、…  登録日、締切日、… 不変 -> 振舞の安定  パラメータ付コンストラクタで生成  set メソッド禁止  演算結果は、新たにオブジェクトを生成して返す  String と同じ
  32. 32. 6つの役割で考えるオブジェクトデザイン by ワーフスブラック 外部への見せ方 <<interface>> 部品群の構造化 全体 <<structurer>> 制御役 調整役 <<controller>> <<coordinator>> If/for を 持つ/持たない の違い 情報保持 部品A 部品N <<information holder>> サービス(演算)提供 <<service provider>>
  33. 33. 識別にフォーカスしたクラス 識別番号(参照番号)  発番方法  一意性確保/検証 認証  番号と実体の照合方法、記録 識別名  氏名、品名、…  一意でなくても良い。人間にとっての判断材料。 DDD Entity パターン
  34. 34. 手順やルールをクラスにまとめる Procedure クラス  業務の手順  コンピューティング手順  状態を持たない Policy クラス  オーバーブッキングポリシー  キャンセルポリシー  状態を持たない Rule クラス  Policy クラスの部品
  35. 35. 集約、モジュール、リポジトリ  いつもいっしょに扱う単位 全体  例:注文ヘッダーと明細  例:顧客Entityと連絡先  パッケージ宣言でモジュール化  全体クラス Publicで公開  部品クラス デフォルトで隠蔽  リポジトリで一体操作部品A 部品N  格納する塊(ヘッダと明細)  取り出す塊
  36. 36. その他の参考パターン(1) グルーピング、関連づけ、構造化  「一覧」 <---- List クラスのラッパー  分類(クラス分け、カテゴリー)  グループ /メンバー 、コンテナ/コンテンツ、アセンブリ/パーツ  セット(商品)、パッケージ(販売), オプション・アダプタ・アクセサリ… 予定、約束  スケジュール  契約 通知、連絡、申し送り 責任・権限  部門、役割、ポスト  承認ルート  兼任
  37. 37. その他の参考パターン(2) 照合  多対多の解決  例:売上計上、締と請求、入金消込 日付  予定日、残日数、期限切れ  期間、間隔  日付演算 金額・数量  単位換算  数値演算と精度 場所  識別方法  経度緯度、郵便番号、都道府県・市区町村、番地、最寄駅、沿線、…  包含関係
  38. 38. その他の参考パターン(3) ドメインモデル内の階層化 (関心ごとの分離)  意思決定層  ポリシー、プロシージャ層  オペレーション層  イベント:注文、入出庫、…  ステート:残高、〇〇中,△△待ち、 …  リソース(商品、場所、… )層
  39. 39. チャレンジテーマ1. 隣接ドメインと領域の重なり2. 状態遷移とコミュニケーション3. イベントソーシング4. 基本構造の複雑化5. 時系列変化
  40. 40. 隣接ドメインと領域の重なり 同じもの?  発注/受注/注文  見込み客、顧客、契約者、出荷先、請求先、… 作り方は?  中核部分を共有して密結合?  支援部分を部品として共有?  別々に作って、疎結合?  別々に発展させる vs. 寄せていく
  41. 41. 状態遷移 業務ルールの宝庫  修正可否、取消手順、アラート、締切、督促、… モデリングテクニック  状態機械 (イベント・ステートモデル)  状態遷移表  論理的に記述・検証でき、実装も安定する。 利用者(業務専門家)の用語(メンタルモデル)とのギャップ  「状態」「○○中」「△△待ち」, …  言葉の意味がそもそも違う? (状態機械ではない?)  コミュニケーションのハードル  モデルの間違いの発見の遅れ  テストの自動化
  42. 42. イベントソーシング ビジネスプロセス=イベント駆動 イベントソーシング  元データは、イベントの発生記録(伝票)  ステート(残高や状態、帳簿)は、派生(再構築可能) 非同期メッセージング  ドメイン駆動アーキテクチャの実装技術  業務モデルと親和性が高い(はず)  DBアプリケーション(OLTP)が先行したが、今後の有望分野 課題  モデリング (非同期、並行処理、エラー処理、リトライ、同期ポイント)  設計 (特に、イベントハンドラの変更容易性)  実装  テスト (特にテスト自動化)
  43. 43. 扱う情報の構造の複雑化 かつては、単純で、固定ロジックで対応できた  リスト構造 (線形、連番、順序処理)  単純なツリー構造 (大中小3分類、…) より複雑な構造への要求・期待  マトリクス、キューブ、 ファセット、… ( 多軸の分類整理 )  ネットワーク構造 (関係付けが、縦横無尽) よりアナログ(=人間感覚)に近づける  あいまい/関係づけ/重みづけの検索や判断  Fuzzy 「らしさ」「感覚値」のデータ化と処理ロジック
  44. 44. 時系列の変化変更履歴、追跡、復元、予定、推定、… 異動、組織変更、合併・分社化、… 価格改定、価格変動 評価額、為替レート、… 予定・実績・差異 先物、リスク管理、タイミング管理、…
  45. 45. ありがとうございました。

×