How do you model a domain into well-designed classes?

Question

IT Interview Practice · Accepted Answer

Good class modeling means classes that map to real domain concepts, each with **one clear responsibility**, related through honest **is-a/has-a** relationships, and depending on **abstractions** at the boundaries. There's no formula, but there is a repeatable process. ## A practical process ```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 ``` ## Behavior follows 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); } } ``` ## Heuristics that keep hierarchies healthy | Heuristic | Why | |---|---| | Prefer composition; use inheritance only for true is-a | Avoids fragile base class / LSP traps | | Keep hierarchies shallow (2–3 levels) | Deep trees couple everything | | One reason to change per class (SRP) | Localizes change | | Program to interfaces at seams | Testability, swappability | | Make value objects immutable | Eliminates a class of bugs | ## Pitfall Don't model the *whole* world up front. Start small with concrete classes; extract abstractions only when real variation appears (the rule of three). Speculative hierarchies age badly. ## Why it matters A model that mirrors the domain makes code self-explanatory — a new engineer reads `order.refund()` and understands the business, not just the syntax. The payoff compounds: cohesive, loosely coupled classes localize change, so features and bug fixes touch few files instead of rippling across the system.

Heuristic	Why
Prefer composition; use inheritance only for true is-a	Avoids fragile base class / LSP traps
Keep hierarchies shallow (2–3 levels)	Deep trees couple everything
One reason to change per class (SRP)	Localizes change
Program to interfaces at seams	Testability, swappability
Make value objects immutable	Eliminates a class of bugs

A practical process

Behavior follows data

Heuristics that keep hierarchies healthy

Pitfall

Why it matters

Related questions