ドメインモデルの育て方
•
38 j'aime•13,334 vues
BPStudy #82 2014/6/27 ギルドワークス「正しいものを正しくつくる」、市谷さんとの合体発表。 ドメイン駆動設計。
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à ドメインモデルの育て方
Similaire à ドメインモデルの育て方 (20)
Plus de 増田 亨
Plus de 増田 亨 (20)
ドメインモデルの育て方
- 5. モデリングと設計のパラダイム • 画面・帳票モデル – 画面一覧、画面遷移図、項目定義書、… • 機能モデル – 機能一覧、入出力項目定義、処理詳細、… スマートＵＩ ﾄﾗﾝｻﾞｸｼｮﾝ ｽｸﾘﾌﾟﾄ
- 6. モデリングと設計のパラダイム • 画面・帳票モデル – 画面一覧、画面遷移図、項目定義書、… • 機能モデル – 機能一覧、入出力項目定義、処理詳細、… • データモデル – ER 図、テーブル一覧、テーブル定義書、… スマートＵＩ ﾄﾗﾝｻﾞｸｼｮﾝ ｽｸﾘﾌﾟﾄ Active Record
- 7. モデリングと設計のパラダイム • 画面・帳票モデル – 画面一覧、画面遷移図、項目定義書、… • 機能モデル – 機能一覧、入出力項目定義、処理詳細、… • データモデル – ER 図、テーブル一覧、テーブル定義書、… • オブジェクトモデル – パッケージ図、クラス図、コラボレーション図、… スマートＵＩ ﾄﾗﾝｻﾞｸｼｮﾝ ｽｸﾘﾌﾟﾄ Active Record ドメイン モデル
- 9. 三層＋ドメインモデル プレゼンテーション層 アプリケーション層 データソース層 OrderForm.vm OrderConfirm.vm OrderRegistered.vm @Controller class OrderEntryController … // bind & validate @Service class OrderRegisterService … void register( Order order ) @Repository class OrderDatasource … void save( Order order )
- 10. 三層＋ドメインモデル プレゼンテーション層 アプリケーション層 データソース層 OrderForm.vm OrderConfirm.vm OrderRegistered.vm @Controller class OrderEntryController … // bind & validate @Service class OrderRegisterService … void register( Order order ) @Repository class OrderDatasource … void save( Order order ) ドメインモデル class Order class Items class ShipTo class BillingTo class ContactInfo … interface OrderRepository <<use>> import model.Order ロジックの抽出と移動 矢印の意味
- 12. プロジェクトの進行モデル • プロジェクト初日 – 顔合わせとご挨拶、プロジェクトの概要説明 • 仕様が具体的になり始める – 打合せ、ドキュメント、…
- 13. プロジェクトの進行モデル • プロジェクト初日 – 顔合わせとご挨拶、プロジェクトの概要説明 • 仕様が具体的になり始める – 打合せ、ドキュメント、… • コード量が急速に増え始める – 開発環境が整って、人が集まって、リズムがでてき た
- 14. プロジェクトの進行モデル • プロジェクト初日 – 顔合わせとご挨拶、プロジェクトの概要説明 • 仕様が具体的になり始める – 打合せ、ドキュメント、… • コード量が急速に増え始める – 開発環境が整って、人が集まって、リズムがでてくる • 開発終盤 – 仕様の変更/追加/再定義、バグとの戦い、性能問題
- 15. プロジェクトの進行モデル • プロジェクト初日 – 顔合わせとご挨拶、プロジェクトの概要説明 • 仕様が具体的になり始める – 打合せ、ドキュメント、… • コード量が急速に増え始める – 開発環境が整って、人が集まって、リズムがでてきた • 開発終盤 – 仕様の変更/追加/再定義、バグとの戦い、性能問題 • リリース後 – 障害(バグの発覚)、積み残し開発、追加開発、…
- 16. １．プロジェクトの初日の設計 • パッケージ図 顧客 商品 注文 出荷 売上・請 求・回収 値引き 返品 <<use>> ( = import 文) 業務の基本構造 ＝プログラムの基本構造 参照関係の「複雑」さや「あいまい」さが、設計課題を暗示している ？ ？ ？
- 17. ２．仕様が具体的になりはじめたら • ドメインモデルの基礎部品を増やしていく – 値オブジェクト – 振る舞いを持った区分 – ファーストクラスコレクション • 要求に出てくる「言葉」をマッピング – パッケージ名 – クラス名 – メソッド名 • コード量とクラスの数は比例する – クラスの数が変わらずコードが膨らみはじめたら警戒 警報
- 20. 振る舞いを持った区分 Enum MemberType //会員区分 { normal, silver, gold; Rate chargeRate() String description() Boolean isLimitOver() } 「区分」や「種別」はビジネスルールの存在を示唆 ビジネスルールを記述する場所を準備
- 22. ３．コード量が急速に増え始める • 失敗パターン – 画面単位や機能単位に分担して並行開発 – ビュー、コントローラ、サービスクラスがファットになる – コードの重複 → 変更コストの増大 • 成功パターン – ドメインモデルに業務ロジックを集め続ける – 共有のドメインモデルをみんなでがんがんいじる – 痛い目に合う – そこで逃げない – みんなで会話しながら同じモデルを追いかける
- 23. ４．開発の終盤 • 時間との闘い – 仕様の変更・追加・再定義 – バグとの戦い – 性能問題 • 現実 – モデル一貫性よりも、とにかく修正する – ただし、リファクタリングしたほうが結局は早くて確実なことが多い （スキルレベルによるけど） • Interface と実装の分離 （多態の導入） • 間接化（第３のクラスを導入して、クラスＡとＢの依存関係を無くす） • できれば – リファクタリングする – 最低限、マークしておいて、リファクタリング勉強会のネタにする – それが次のモデル・設計・開発の糧になる
- 24. ５．リリース後 • いろいろ起きる – 障害（バグの発覚） – 積み残し分の開発 – 追加開発 • ドメインモデルの真価がわかる時 – 業務を単純化したモデルが正しいか – モデルをうまくコードで表現できているか • 良いドメインモデルに成長していれば 変更は「楽」で「安全」になる – 修正箇所の特定 – 修正範囲の局所化 – 副作用の局所化 • リリース後のソフトウェアの成長に立ち会い続けること が、ドメイン駆動設計を会得する王道
- 26. 三層＋ドメインモデル プレゼンテーション層 アプリケーション層 データソース層 OrderForm.vm OrderConfirm.vm OrderRegistered.vm @Controller class OrderEntryController … // bind & validate @Service class OrderRegisterService … void register( Order order ) @Repository class OrderDatasource … void register( Order order ) ドメインモデル class Order class Items class ShipTo class BillingTo class ContactInfo … interface OrderRepository <<use>> import model.Order ロジックの抽出と移動 矢印の意味