Downloaded 106 times
More Related Content
![ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]](https://cdn.slidesharecdn.com/ss_thumbnails/2022-220117111455-thumbnail.jpg?width=640&height=640&fit=bounds)
私がドメイン駆動設計をやる理由
- 1.
- 2. ソフトウェアの変更に 苦しんでいませんか？ • どこに何が書いてあるか、わからない • ちょっとした変更なのに、あちこち修正が必要 •副作用が怖くて、既存コードがいじれない …
- 3.
- 4.
- 5.
- 6. ドメイン駆動設計 before - after これ以上なにもできないソフトウェア成長力のあるソフトウェア
- 7. ドメイン駆動設計のエッセンス • モデル駆動 • 三層＋ドメインモデル •チームをドメイン駆動に
- 8.
- 9. モデル駆動 • 現実世界の「関心事の模型」をつくる – 単純化（要点と基本の構造） •クラス図っぽい絵 • 言葉 – 会話（打合せ、雑談、…) – 文章（メール、wiki、issue、commit , … ) • 「関心事の模型」をコードで表現 – 動くソフトウェア – プログラミング言語／フレームワーク／実行環境とい う「制約」 • 改善を繰り返す
- 10.
- 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. ソフトウェアの変更に 苦しんでいませんか？ • どこに何が書いてあるか、わからない • ちょっとした変更なのに、あちこち修正が必要 •副作用が怖くて、既存コードがいじれない …
- 25.