- 日時 : 2012/03/05 19:00 to 21:00
- 講師 : 増田 亨(masuda220)
- 会場 : フルネス・トレーニングルーム@中野 （東京都中野区新井1-25-6 中野フコク生命ビル4F）
- URL : http://atnd.org/events/25353
- 資料 : http://www.slideshare.net/masuda220/ss-11869005
- ドメインモデルとは利用者の関心ごとの模型
- 利用者の関心ごとの実装
- com.systemsekkei.model.*
ドメインモデル 利用者の関心ごとの模型 この設計・実装を開発の中心にする
- 原則に設計してからコード
- もうひとつのDDD(Design-Driven Development)
- MDD:Model-Driven Design
- 言葉と絵で、関心ごとの模型を作って、設計、実装
- 少しずつ、継続的に成長
- iterate
- increment
- continuous
- TDD
- BDD
- UCDD
- TiDD
- ScrDD(画面駆動開発)
- ExDD(Excel駆動開発)
- RD/AC(リスク駆動・アーキテクチャ中心)
xDDやればOKというプロジェクトなんて存在しないことが多い。 悪路走破には、四輪駆動。つまり、マルチxDD。 そうはいってもより速く、より効率的にやりたいよね。
- DDD
- TDD
- BDD
- UCDD
- TiDD
- ScrDD(画面駆動開発)
- ExDD(Excel駆動開発)
- RD/AC(リスク駆動・アーキテクチャ中心)
- 利用者の要求のキャッチ力が高まる
- 利用者の関心ごとの構造が見えてくる
- 要件の追加や変更が簡単で安全になる
-
設計原則 : 関心の分離
- SRP : 単一責任の原則
- カプセル化、情報隠蔽
-
設計原則 : 協調
- 疎結合:必要最小限の結合関係
- モジュール化(公開インタフェースの最小化)
設計原則をドメインモデルに適用していく
- 基本パターン:Whole-Part
- 関心の分離+協調の基本パターン
- 繰り返し、適用シーンがでてくる、基本中の基本パターン
- 全体クラスの設計は有用で一番シンプルなインターフェイスは何かを設計すること
- 部品は関心ごとに単一責任の原則で設計する
- 部品をどう使うのか全体クラスの内部設計になる
- 全体クラスがコントロールするのか部品クラスに委譲するのかも設計しなければならない
- 全体クラスにif文が多くなり変更に柔軟でなくなる
- 利用者の関心ごとの置き場所を作る
- 利用者の関心ごとを見つける
- 利用者の関心ごとのコードにしてある
- 利用者の関心ごとの妥当性(ユーザにとって価値があるかどうか)を検証する
- 利用者の関心ごとの改善点を発見する
技術面で関心の分離を行う
- 画面
- UIコントローラ
- DBアクセス
- メール送信
- メッセージング
利用者の関心ごとを記述するクラス群を作成する
各コンポーネント からは 利用する 依存関係
利用者の関心ごとを記述するクラス群は誰から使われているか知らない
Javaであればimport文をチェックして依存関係を調べられる
- 顧客登録サービス( << application controller >> )
- 顧客( << domain object >> )
- 連絡方法
- 連絡先() : メールアドレス
- 顧客レポジトリ( << interface >> )
- 登録する() : void
- 存在を確認(顧客) : Boolean
- 顧客トランスファー( << interface >> )
- Thank Youメール送る(顧客) : void
- 関係部門に通知する(顧客) : void
- Velocityテンプレート
- Spring Bind
- Bean Validation
- Spring MVC
- Spring WebFlow
- Spring ORM
- MyBatis(SQLマップ)
- Spring Mail
- Apache James
- Spring JMS
- ActiveMQ
- MuleESB
Spring Bind と Bean Validation はおすすめ
まずは
- 置き場所を作る
- モデルにパッケージを作る
- 最低1つクラスを作る
- 最低1つメソッドを作る
あとは、以下を繰り返す
- 顧客の言葉/業務要件を手がかりに
- サブパッケージ追加
- クラス追加
- フィールド追加
- メソッド追加
- ごちゃごちゃしているので整理整頓
- 名前の変更
- クラスの移動
- フィールドの移動
- メソッドの移動
- まずは、やってみる
- つまづく
- 本を漁る
- 対象業務のハンドブックや入門書
- 出来れば英語本
- 英語本はパッケージ名、クラス名、メソッド名の宝庫
- 技術書ではない
- 試してみる
- 工夫してみる
詳しくはリファクタリング書籍を参照
- 「業務の関心ごと」の分離
- 手続型の設計(手続+データ)をドメインオブジェクトにリフォーム
- 条件記述から業務ロジックを抽出
- コレクションのカプセル化
- 技術的な関心 -> 業務の関心
- 実際欲しい情報を属性として持っておく
- 属性をこねくり回したら取得できるからOKではない
- 単なる値をドメインブジェクトに昇格する
- 業務ドメインによく出てくる設計パターン
- 用語や概念
- 何が関心ごとか？
- どう設計するか？
- パターン集の目次
- さまざまな関心ごとを俯瞰する全体マップ
- パターン=設計のヒント
- 関心の分離
masuda220リストマニア「ドメインモデル設計パターン」@アマゾン
- ドメイン駆動設計 by Evans
- まえがき
- 第1部
- ビジネスパターンによるモデル駆動設計 by Hruby
- 2章 構造パターン
- 5章 振る舞いパターン
- アナリシスパターン by Fowler
- A.1.4 基本型
- PoEAA by Fowler
- はじめに
- 2章 ドメインロジックの選択
- リファクタリング by Fowler
- 3章 変更の発散、変更の分散
- ストリームラインオブオブジェクトモデリング by ニコラ
- 3章 協調パターン
- UMLによるビジネスモデリング by エリクソン
- 5章 ビジネスルール
- The Data Model Resource Book 1,2,3
- Data Model Pattern by Hay
- 基本語彙の設計・実装パターン
- String, BigDecimal, Date/longのラッパー
- 型宣言->表現力の向上
- 氏名、社名...
- 金額、数値、日数...
- 登録日、締切日...
- 不変 -> 振舞の安定
- パラメータ付コンストラクタで生成
- setメソッド禁止
- 演算結果は、新たにオブジェクトを生成して返す
- String と同じ
オブジェクトデザイン by ワーフスブラック
- 情報保持
- サービス演算提供
- 外部への見せ方
- 部品群の構造化
- 制御役
- 調整役
DDD Entityパターンに載ってるので参照する
- 識別番号
- 発番方法
- 一意性確保/検証
- 認証
- 番号と実態の照合方法、記録
- 識別名
- 氏名、品名
- 一意でなくても良い、人間にとっての判断材料
あとは資料見てね^^
プロシージャクラスとかポリシークラスも作っちゃえば良いじゃん。
ただし必ずステートレスにしとく。
部品はJavaのデフォルトを使うと良い
- 隣接ドメインと領域の重なり
- 受注、発注、注文(概念)
- 顧客は曖昧する
- どういう考え方にすれば良いか難しくて悩ましい
- 状態遷移
- 状態遷移はビジネスルールの宝庫
- 状態遷移は非常に有用なツールであるが、顧客からのフィードバックが得られなくて悩ましい
- イベントソーシング
- 詳しくはネットで調べてね
- 考え方はOK
- テストまで考えるとまだ出来てないので悩ましい
- マトリックスや多次元分析のデータの扱い方が悩ましい
- 時系列ビックデータをどう扱うのか悩ましい
- ドキュメントどうしてますか？
- EA使ってます。
- 顧客用には別ドキュメントを作らざろう得ない
- でもツールでの自動化をがんばったり、ドキュメントを作らないようにしたり工夫している
- 改善ポイントを見つけて改善していくしかない
- 例外/禁則をモデル図で扱うのが難しい
- 言葉を見つけたらクラス化している
- 例外の言葉もクラス化している
- どうやって協調させるとかは後で考えれば良い
- 状態遷移図はOCL制約で書けたりする