ドメイン駆動設計 ( 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コントローラＤＢアクセスメール送信利用者の関心ごとを記述する場所メッセージング

依存関係画面 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 ; }} elseelse {{ 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 「らしさ」「感覚値」のデータ化と処理ロジック

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

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

http://d.hatena.ne.jp	710
https://twitter.com	12
http://s.deeeki.com	5
http://webcache.googleusercontent.com	3
https://twimg0-a.akamaihd.net	1
https://si0.twimg.com	1
http://cache.yahoofs.jp	1

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

by 増田亨 on Mar 05, 2012

Accessibility

Categories

Upload Details

Usage Rights

7 Embeds 733

Statistics