What is a Domain Model in OOP?
Learn what a domain model is in OOP — entities, value objects, and business rules as behavior — with a Java example and interview questions.
Expected Interview Answer
A domain model is an object-oriented representation of the real-world concepts, rules, and relationships in a business area, where classes map to nouns like Order or Customer and their methods encode the actual business behavior and invariants.
Unlike a plain data structure, a domain model puts behavior next to the data it governs — an Order class validates its own state transitions rather than exposing raw fields for external code to mutate freely. It captures entities (objects with identity, like a Customer), value objects (immutable descriptors, like Money), and the relationships and rules that connect them, such as "an Order cannot be shipped until payment is confirmed." Building a rich domain model is central to domain-driven design, and it stands in contrast to an anemic model where classes are just getters/setters and all logic lives in separate service classes. A well-formed domain model makes the code read like the business itself, so developers and domain experts can share the same vocabulary (ubiquitous language).
- Encodes business rules where the data lives, preventing invalid states
- Gives developers and domain experts a shared vocabulary
- Keeps behavior discoverable instead of scattered across services
- Makes the codebase resilient to changing business rules
AI Mentor Explanation
A cricket scoring app models real concepts as classes: an Innings object knows it cannot record a seventh ball in an over, and a Batsman object enforces that a retired-out player cannot resume batting unless recalled under specific rules. The rules live inside the objects that own the data, not in a separate rulebook nobody consults. That is a domain model: classes named after real cricket concepts that carry the actual rules of the game as behavior, not just fields to be filled in.
Step-by-Step Explanation
Step 1
Identify the core nouns
Find the real-world entities and value objects the business talks about (Order, Customer, Money).
Step 2
Attach behavior, not just fields
Give each class the methods that enforce its own business rules and invariants.
Step 3
Model relationships explicitly
Represent associations and constraints between entities (an Order has one Customer, many LineItems).
Step 4
Share the vocabulary
Name classes and methods using the same terms domain experts use, so the model stays a shared language.
What Interviewer Expects
- A definition distinguishing a domain model from a plain data-transfer object
- Mention of entities, value objects, and invariants
- Awareness of the anemic domain model anti-pattern
- A concrete example of a business rule enforced inside a class method
Common Mistakes
- Treating a domain model as just a set of database tables mapped to classes
- Building an anemic model where all logic lives in external service classes
- Confusing a domain model with a DTO or view model used for the UI
- Not knowing the term “ubiquitous language” from domain-driven design
Best Answer (HR Friendly)
“A domain model is how we represent the real concepts of a business — like an Order or a Customer — as classes that carry both their data and the rules that govern them. Instead of having plain data objects and separate logic files, the class itself enforces things like "an order can’t ship before payment is confirmed," which keeps the rules close to the data and easier to trust.”
Code Example
class Order {
private OrderStatus status = OrderStatus.PENDING;
private boolean paymentConfirmed = false;
void confirmPayment() {
this.paymentConfirmed = true;
}
void ship() {
if (!paymentConfirmed) {
throw new IllegalStateException("Cannot ship before payment is confirmed");
}
this.status = OrderStatus.SHIPPED;
}
}
enum OrderStatus { PENDING, SHIPPED, DELIVERED }
Order order = new Order();
order.confirmPayment();
order.ship(); // rule enforced inside the domain object itselfFollow-up Questions
- What is the difference between a domain model and an anemic model?
- What is the difference between an entity and a value object?
- How does a domain model relate to domain-driven design?
- How would you keep a domain model independent of your persistence layer?
MCQ Practice
1. A domain model is best characterized by?
A domain model bundles business data together with the methods that enforce its rules and invariants.
2. A domain model where all classes are just data holders with logic living elsewhere is called?
The anemic domain model anti-pattern strips behavior out of entities, leaving them as plain data containers.
3. Which concept describes an immutable object defined only by its attributes, with no identity, inside a domain model?
A value object (like Money) is defined by its attributes and has no identity of its own, unlike an entity.
Flash Cards
Domain model in one line? — Classes representing real business concepts, carrying both data and the rules that govern it.
Opposite anti-pattern? — Anemic domain model — data-only classes with logic in separate services.
Entity vs value object? — Entity has identity (Customer); value object has none, defined by attributes (Money).
Term for shared vocabulary? — Ubiquitous language, from domain-driven design.