ドメインをよく設計されたクラスにモデル化するには、どうすればよいですか？

Question

Accepted Answer

良いクラスモデリングとは、実際のドメイン概念にマップするクラスであり、それぞれが**1つの明確な責任**を持ち、正直な**is-a/has-a**関係を通じて関連付けられ、境界での**抽象化**に依存しているということです。公式はありませんが、繰り返し可能なプロセスがあります。 ## 実践的なプロセス ```text 1. Find the NOUNS → candidate classes (Order, Customer, Payment) 2. Find the VERBS → candidate behaviors/methods (place, refund, ship) 3. Assign each behavior to the class that OWNS the data it needs (high cohesion) 4. Choose relationships: IS-A (rare, must pass LSP) vs HAS-A (default) 5. Depend on interfaces at boundaries (DIP); inject volatile dependencies 6. Keep invariants inside the object (encapsulation); prefer immutability for values ``` ## 動作はデータに従う ```java // ❌ logic separated from data (anemic) → low cohesion class Order { List items; } class OrderCalculator { double total(Order o) {...} } // ✅ behavior lives with the data it operates on class Order { private final List items; public Money total() { // owns its own rule return items.stream().map(Item::price).reduce(Money.ZERO, Money::plus); } } ``` ## 階層を健全に保つヒューリスティック | ヒューリスティック | 理由 | |---|---| | 合成を優先; 真の is-a の場合のみ継承を使用 | 脆い基本クラス / LSP トラップを回避 | | 階層を浅く保つ (2–3 レベル) | 深いツリーはすべてを結合 | | クラスごとに変更の理由は1つ (SRP) | 変更をローカライズ | | 継ぎ目でインターフェースにプログラミング | テスト性、交換可能性 | | 値オブジェクトを不変にする | バグのクラスを排除 | ## 落とし穴最初から*世界全体*をモデル化しないでください。具体的なクラスから小さく始め、実際のバリエーションが現れた場合にのみ抽象化を抽出してください (3の法則)。投機的な階層は経年劣化します。 ## なぜ重要なのかドメインを反映するモデルはコードを自己説明的にします — 新しいエンジニアが `order.refund()` を読むと、構文ではなくビジネスを理解できます。見返りは複利で増えます: 凝結度の高い、疎結合なクラスは変更をローカライズするため、機能とバグ修正はシステム全体に波及するのではなく、少数のファイルに限定されます。

ヒューリスティック	理由
合成を優先; 真の is-a の場合のみ継承を使用	脆い基本クラス / LSP トラップを回避
階層を浅く保つ (2–3 レベル)	深いツリーはすべてを結合
クラスごとに変更の理由は1つ (SRP)	変更をローカライズ
継ぎ目でインターフェースにプログラミング	テスト性、交換可能性
値オブジェクトを不変にする	バグのクラスを排除