Hoe modelleer je een domein in goed ontworpen klassen?

Question

Accepted Answer

Goed klasse modelleren betekent klassen die overeenkomen met echte domeinconcepten, elk met **één duidelijke verantwoordelijkheid**, verbonden door eerlijke **is-a/has-a** relaties, en afhankelijk van **abstractions** aan de grenzen. Er is geen formule, maar wel een herhaalbaar proces. ## Een praktisch proces ```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 ``` ## Gedrag volgt data ```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); } } ``` ## Heuristieken die hierarchieën gezond houden | Heuristiek | Waarom | |---|---| | Geef voorkeur aan compositie; gebruik inheritance alleen voor echte is-a | Vermijdt fragile base class / LSP valkuilen | | Houd hierarchieën ondiep (2–3 niveaus) | Diepe bomen koppelen alles | | Één reden voor verandering per klasse (SRP) | Lokaliseert verandering | | Programmeer naar interfaces bij grenzen | Testbaarheid, uitwisselbaarheid | | Maak value objects onveranderlijk | Elimineert een klasse bugs | ## Valkuil Modelleer niet de hele wereld van tevoren. Begin klein met concrete klassen; extraheer abstracties alleen wanneer echte variatie verschijnt (de regel van drie). Speculatieve hierarchieën verouderen slecht. ## Waarom het belangrijk is Een model dat het domein weerspiegelt maakt code zelfverklarend — een nieuwe engineer leest `order.refund()` en begrijpt het bedrijf, niet alleen de syntaxis. De voordelen groeien samen: cohesieve, losjes gekoppelde klassen lokaliseren verandering, dus features en bugfixes raken slechts enkele bestanden in plaats van zich door het systeem uit te breiden.

Heuristiek	Waarom
Geef voorkeur aan compositie; gebruik inheritance alleen voor echte is-a	Vermijdt fragile base class / LSP valkuilen
Houd hierarchieën ondiep (2–3 niveaus)	Diepe bomen koppelen alles
Één reden voor verandering per klasse (SRP)	Lokaliseert verandering
Programmeer naar interfaces bij grenzen	Testbaarheid, uitwisselbaarheid
Maak value objects onveranderlijk	Elimineert een klasse bugs