私がドメイン駆动设计をやる理由
- 2. ソフトウェアの変更に 苦しんでいませんか？ ? どこに何が書いてあるか、わからない ? ちょっとした変更なのに、あちこち修正が必要 ? 副作用が怖くて、既存コードがいじれない …
- 6. ドメイン駆動設計 before - after これ以上なにもできないソフトウェア 成长力のあるソフトウェア
- 7. ドメイン駆動設計のエッセンス ? モデル駆動 ? 三層＋ドメインモデル ? チームをドメイン駆动に
- 9. モデル駆動 ? 現実世界の「関心事の模型」をつくる – 単純化（要点と基本の構造） ? クラス図っぽい絵 ? 言葉 – 会話（打合せ、雑談、…) – 文章（メール、wiki、issue、commit , … ) ? 「関心事の模型」をコードで表現 – 動くソフトウェア – プログラミング言語／フレームワーク／実行環境とい う「制約」 ? 改善を繰り返す
- 11. プロジェクト初日の関心事模型 ? パッケージ図 顧客 商品 注文 出荷 売上?請 求?回収 値引き 返品 <<use>> ( = import 文) 関心事の基本構造 ＝プログラムの基本構造 参照関係の「複雑さ」や「あいまいさ」が、設計課題を暗示している ？ ？ ？
- 12. 三層＋ドメインモデル ? 業務視点でコードを整理する枠組み – このアーキテクチャに移行したのが、ドメイン駆動設計 実践のターニングポイントだった – 業務の関心事を「ドメインモデル」に集約する ? 業務の関心事の構造をプログラムの構造に反映 – どこに何が書いてあるか「業務の関心事」の視点で、 コードを整理する – 変更の依頼があった時に、変更箇所が探しやすくなる – 業務的に関連しない箇所で、変更の副作用が起きな くなる
- 13. 三層アーキテクチャの問題 プレゼンテーション層 アプリケーション層 データソース層 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 ) 業務ロジックの断片が まぎれこみがち かつ その断片が複数画面に 重複しがち 複数の機能に 同じロジックが重複しがち 業務ロジックの断片が まぎれこみがち かつ 複数の機能や画面用に 同じコードを書きがち
- 14. 三層＋ドメインモデル プレゼンテーション層 アプリケーション層 データソース層 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 業務ロジックの抽出と移動 矢印の意味
- 15. ドメイン駆動設計にたどりつくまで ? 大炎上プロジェクト ? 分岐点 ? チームがドメイン駆动に変わっていく
- 16. 大炎上プロジェクト ? バグだらけ – 変更画面は使用不可、レポート出力タイムアウト、他のユーザのデータ が丸見え、データ整合性チェックバッチ、… ? リファクタリングやりほうだい – いまより悪くなるわけない – 一か月くらい、毎日２回本番リリース ? リファクタリングの効果絶大／面白いほどコード整理が進んだ – 名前の変更 – 説明用変数 – メソッドの抽出 – クラスの抽出 – ビューとモデルの分離 – モデルとデータベース操作の分離 …
- 17. ドメイン駆動設計への分かれ道 ? クラス構成やレイヤ構成で意見に違いがでてきた – 技術視点のコード整理 – 業務視点のコード整理 ? 技術視点のコード整理 – ネタは盛りだくさん – 当時発展しつつあった、Webアプリケーションのフレー ムワークやツール導入の誘惑 ? 業務視点のコード整理 – 障害は業務的なものばかり ? テクニカルには正しく動くようになってきていた – 機能の追加?修正の要求は業務的なものばかり
- 18. 業務視点のコード整理 ? 三層＋ドメインモデルのアーキテクチャ – ターニングポイント – 業務の関心事構造＝プログラムの構造 – 業務の用語を、パッケージ名／クラス名／メソッド 名／引数名／変数名に反映 ? 業務視点のリファクタリング – 初期の設計よりも、継続的な設計改善がポイント ? 改善する機会が多い ? 累積効果も大きい
- 19. チームがドメイン駆动に変わっていく ? 業務視点でコードを整理する効果の実感 ? 手続型からオブジェクト指向へ ? 技术视点から业务视点へ
- 20. 業務視点でコードを整理する効果の実感 ? 業務視点のリファクタリング – やり方と効果を実感できると、がらっと変わる – 障害対応や機能追加が絶好のチャンス – 変更の前に「必ずやるべき作業」として徹底する ? 業務ロジックの重複記述を発見する – メソッドやクラスに抽出して重複をなくしておく ? 他のレイヤの業務ロジックの断片を発見する – メソッドに抽出して、ドメインのクラスに移動しておく ? 効果 – 変更すべき箇所を特定しやすい – 変更するコード量が減る – 変更の影響範囲がローカルになり、副作用の心配が減る – 自信を持って変更できる
- 21. 手続き型からオブジェクト指向へ ? 最初は小学生ルール – メソッドやクラスの行数とか、引数の数とか – 「リファクタリング」の「いやな臭い」の勉強会 – 怪しい箇所／直すべき箇所の臭いがだんだんわかってくる ? 設計改善の基本テクニックの習得 – メソッドの抽出 – ガード節と早期リターン – Value Object – ファーストクラスコレクション – 振る舞いを持った定数 – 「区分」ごとのサブクラス化 ? 区分ごとのロジックをそれぞれ専用クラスに分ける ? 「業務視点のリファクタリング」の徹底 – 業務ルール（加工、判断、計算）をメソッド化する – 業務用語のクラス化／パッケージ化 – 改善を繰り返す（放置すると劣化する）
- 22. 技术视点から业务视点へ ? 語彙力 – 業務用語の「語彙」を増やす（使う機会を増やす） – 会話や文書で「業務用語」の正しい使い方を確認 – 似た用語の「使い分け」の練習 ? ビジネス論理力 – 顧客の関心度の強弱を当てる練習 ? Ｑ&Ａや状況説明などで、業務のいちばんの関心事（用語）を一番最初 に持ってくる練習 ? whatとwhyの説明に業務の用語をちりばめる練習 ? 断片化しあちこちにちらばった業務ロジックの発見ゲーム – ビュー – コントローラ – データベースアクセス ? 技術者だけで話す時に、使う言葉が変わってきたら、本物
- 23. チームがドメイン駆动に変わっていく ? 業務視点でコードを整理する効果の実感 ? 手続型からオブジェクト指向へ ? 技术视点から业务视点へ
- 24. ソフトウェアの変更に 苦しんでいませんか？ ? どこに何が書いてあるか、わからない ? ちょっとした変更なのに、あちこち修正が必要 ? 副作用が怖くて、既存コードがいじれない …