Wie modellieren Sie eine Domäne in gut gestalteten Klassen?

Question

Accepted Answer

Gutes Klassen-Modeling bedeutet Klassen, die echten Domänenkonzepten entsprechen, jede mit **einer klaren Verantwortung**, verbunden durch ehrliche **is-a/has-a**-Beziehungen und abhängig von **Abstraktionen** an den Grenzen. Es gibt keine Formel, aber es gibt einen wiederholbaren Prozess. ## Ein praktischer Prozess ```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 ``` ## Verhalten folgt Daten ```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); } } ``` ## Heuristiken, die Hierarchien gesund halten | Heuristik | Warum | |---|---| | Bevorzugen Sie Komposition; verwenden Sie Vererbung nur für echte is-a | Vermeiden Sie fragile base class / LSP-Fallen | | Halten Sie Hierarchien flach (2–3 Ebenen) | Tiefe Bäume koppeln alles | | Ein Grund zur Änderung pro Klasse (SRP) | Lokalisiert Änderung | | Programmieren Sie gegen Schnittstellen an den Grenzen | Testbarkeit, Austauschbarkeit | | Machen Sie value objects unveränderlich | Eliminiert eine ganze Klasse von Fehlern | ## Fallstricke Modellieren Sie nicht die *ganze* Welt von vorne. Beginnen Sie klein mit konkreten Klassen; extrahieren Sie Abstraktionen nur, wenn echte Variation auftritt (die Regel der drei). Spekulative Hierarchien altern schlecht. ## Warum es wichtig ist Ein Modell, das die Domäne widerspiegelt, macht Code selbsterklärend — ein neuer Ingenieur liest `order.refund()` und versteht das Geschäft, nicht nur die Syntax. Der Nutzen steigt: kohärente, lose gekoppelte Klassen lokalisieren Änderung, sodass Features und Bugfixes nur wenige Dateien berühren, statt sich durchs ganze System auszubreiten.

Heuristik	Warum
Bevorzugen Sie Komposition; verwenden Sie Vererbung nur für echte is-a	Vermeiden Sie fragile base class / LSP-Fallen
Halten Sie Hierarchien flach (2–3 Ebenen)	Tiefe Bäume koppeln alles
Ein Grund zur Änderung pro Klasse (SRP)	Lokalisiert Änderung
Programmieren Sie gegen Schnittstellen an den Grenzen	Testbarkeit, Austauschbarkeit
Machen Sie value objects unveränderlich	Eliminiert eine ganze Klasse von Fehlern