ドメイン駆動設計の学習曲線とブレークポイント
•Download as PPTX, PDF•
28 likes•8,333 views
ドメイン駆動設計の実践力に転機が訪れる時。 チームがオブジェクト指向を体で覚えた時。 チームがインクリメンタルな設計を体で覚えた時。 チームでオブジェクト指向とインクリメンタルな設計を体で覚えるための指針。 QCon Tokyo 2016
ドメイン駆動設計の学習曲線とブレークポイント
- 4. ドメイン駆動設計 4
- 15. ９つのルール 1. 一つのメソッドでインデントは一段階 2. else 句は使わない 3. すべてのプリミティブ型と文字列をラップする 4. 一行につきドットは１つまで 5. 名前を省略しない 6. すべてのエンティティを小さくする 7. 一つのクラスのインスタンス変数は２つまで 8. ファーストクラスコレクションを使う 9. getter, setter, プロパティを使わない 15
- 16. 名前をつける 1. 一つのメソッドでインデントは一段階 2. else 句は使わない 3. すべてのプリミティブ型と文字列をラップする 4. 一行につきドットは１つまで 5. 名前を省略しない 6. すべてのエンティティを小さくする 7. 一つのクラスのインスタンス変数は２つまで 8. ファーストクラスコレクションを使う 9. getter, setter, プロパティを使わない 16 パッケージ クラス メソッド 小さい単位で 名前をつける
- 17. データとロジックを凝集させる 1. 一つのメソッドでインデントは一段階 2. else 句は使わない 3. すべてのプリミティブ型と文字列をラップする 4. 一行につきドットは１つまで 5. 名前を省略しない 6. すべてのエンティティを小さくする 7. 一つのクラスのインスタンス変数は２つまで 8. ファーストクラスコレクションを使う 9. getter, setter, プロパティを使わない 17 値オブジェクト ファーストクラス コレクション データとロジックを別の場所におかない
- 18. 複数の関心事を持たない 1. 一つのメソッドでインデントは一段階 2. else 句は使わない 3. すべてのプリミティブ型と文字列をラップする 4. 一行につきドットは１つまで 5. 名前を省略しない 6. すべてのエンティティを小さくする 7. 一つのクラスのインスタンス変数は２つまで 8. ファーストクラスコレクションを使う 9. getter, setter, プロパティを使わない 18 ルールに違反している時は、複数の関心事が混在している
- 21. いやな臭い • コードが重複している • メソッドが長い • クラスが大きい • 引数が多い • データとロジックの置き場所が別のクラスに 分かれている 21
- 22. 設計の改善 • 名前の変更 – 業務の関心事と実装を一致させる • メソッドの抽出 – 手続きに名前をつける • クラスの抽出 – 手続きのグループに名前を付ける • メソッドの移動／フィールドの移動 – データとロジックの置き場所を同じクラスにする 22
- 25. 技術方式 レイヤ構造 • 三層構造ではなく、 三層＋ドメイン層 • O-Rマッピング – データクラス＋機能クラス（手続き型）になりがち なツールは避ける • JPA, Active Record, Entity Framework、… – オブジェクトが主役の軽量のツールを選ぶ • myBatis, Spring JDBCTemplate, … 25
- 26. プログラミング言語 • 静的な型付き言語 • 独自の型の定義 – 標準ライブラリの型（クラス）は汎用的すぎる – 目的特化の型をどんどん作る • 型名を明記して意図を表現する – メソッドの返す型、メソッドの引数の型 – インスタンス変数の型 – ローカル変数の型 • 型の設計変更に強い – リファクタリングを楽に安全に 26
- 38. できない理由？ • 今のプロジェクトでは無理 • 今のチームでは無理 • 今の会社では無理 • 今の自分では無理 … 38
- 39. • どんな状況でも改善できる • どんなときでも「あなた」から改善を始められる • どんなときでも「今日」から改善を始められる エクストリームプログラミングの 「はじめに」に記された ケント・ベックのメッセージ 39 その一歩を踏み出そう