ドメイン駆動設計の実践 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 ; }} 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 ; } 業務の重要な関心事（顧客）を記述する入れ物ができた

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

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

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

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

https://twitter.com	36
http://a0.twimg.com	13
http://s.deeeki.com	3
http://us-w1.rockmelt.com	3
http://pub.ne.jp	2
http://b.hatena.ne.jp	1

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

by 増田亨

Accessibility

Categories

Upload Details

Usage Rights

6 Embeds 58

Statistics