Domain & object modeling
Domain modeling fundamentals
Domain modeling means naming the real-world concepts and deciding who owns each responsibility — before naming design patterns. Example: two candidates draw the same boxes — ParkingLot, Floor, Spot, Ticket. One then asks the only question that matters: who allocates a spot? The other opens with “I will use Strategy and Factory.” Same nouns; only one design.
A is not a pile of Manager classes. It is the set of lasting ideas and the verbs those ideas are allowed to perform. Patterns come after you know who owns each verb.
The real question
Who should allocate a spot — and who must not?
If you cannot answer that, Strategy is decoration. If you can, Strategy has a caller.
Candidate A
Starts from the problem
Names the lot, the floors, the spots. Says the lot owns floors. Says a spot protects occupancy. Says allocation needs a view of free spots, so a strategy sits next to the lot. Says pricing is a different decision and must not live on the spot list. Then draws a repository because a ticket will be looked up later.
Candidate B
Starts from pattern names
Writes Factory, Strategy, Singleton, Observer on the board before a single verb has a home. ParkingLot becomes a script that walks spots, computes money, writes SQL, and prints a receipt. The interviewer already knows the ending: one class that is the entire system.
What lasts, and what is only a process
Domain modeling is deciding what exists in the problem and what each thing is allowed to do. You name the ideas that last. You name the verbs. Then you give each verb a . A parking lot contains floors. Floors contain spots. That is : if the lot goes away, so do the floors. Allocation is a decision that needs a view of free spots. Pricing is a decision that needs time and a policy, not the spot list. A ticket is a record you will look up later. It wants an identity and a store. It is not a field that is also a database.
If ParkingLot walks every spot, computes money, writes SQL, and prints a receipt, you do not have a domain model. You have a script with class names. Interviewers see that script immediately. The fix is not “add more classes.” The fix is to ask, for every verb, which object already has the facts — and if none does, whether you need a small coordinator instead of a God object.
Noun workshop
These six types show up in almost every parking-lot round. If a type is missing, the verb that needed it will hide inside a Manager.
ParkingLot
Owns floors. Starts park and exit.
Floor
Owns spots. Answers “what is free here?”
ParkingSpot
Protects occupancy. One vehicle or none.
Vehicle
Plate, size, powertrain. No parking logic.
Ticket
Identity of a stay. Status, times, fee.
Money
Integer paise plus currency. Immutable.
Verb workshop
A verb without a home becomes process(). A verb with two homes becomes a race.
| Verb | Belongs on | Common trap |
|---|---|---|
| allocate | A strategy the lot calls | Floor walking every spot from a controller |
| occupy | ParkingSpot | setOccupied(true) from a webhook |
| price | A pricing policy | A switch on Ticket |
| pay / close | Ticket | ParkingLotService.setStatus |
| remember | TicketRepository | Ticket that is also a database |
| notify | Outside the domain | Spot sending SMS |
A first sketch that is already a model
The sketch below is not “done.” It is honest. The lot owns floors. Allocation and pricing are roles, not methods stuffed into the lot. Tickets are remembered by a store. Occupancy lives on the spot. That is enough structure to survive “now add EV spots” and “now price by airport rules.”
class ParkingLot {
private final List<Floor> floors = new ArrayList<>();
private final SpotAllocationStrategy allocation;
private final PricingStrategy pricing;
private final TicketRepository tickets;
ParkingLot(
SpotAllocationStrategy allocation,
PricingStrategy pricing,
TicketRepository tickets) {
this.allocation = allocation;
this.pricing = pricing;
this.tickets = tickets;
}
Ticket park(Vehicle vehicle) {
ParkingSpot spot = allocation
.choose(freeSpots(), vehicle)
.orElseThrow(() -> new IllegalStateException("lot full"));
if (!spot.tryOccupy(vehicle)) {
throw new IllegalStateException("spot raced");
}
Ticket ticket = Ticket.issue(spot.id(), vehicle);
tickets.save(ticket);
return ticket;
}
}Notice what is missing on purpose. There is no calculateFee on the lot. There is no SQL. There is no SMS. Those verbs have other homes. The lot starts the use case and then gets out of the way. That is the difference between a model and a script.
Ownership tree you can say out loud
Say this sentence in the interview: “The lot owns floors. Floors own spots. A ticket names a spot. A strategy chooses. A policy prices. A store remembers.” That sentence is the design. Everything else is detail.
ParkingLot ├── Floors │ └── ParkingSpots // composition: die with the lot ├── SpotAllocationStrategy // seam: nearest, random, EV-first ├── PricingStrategy // seam: hourly, airport, event └── TicketRepository // association: tickets outlive a stay
Lot / floor / spot
Physical structure. Composition. Nobody else creates a spot.
Policies
Allocation and pricing change. Leave a .
Records
Tickets are . Money is a .
Four moves, in order
- 01
Name what lasts
Lot, floor, spot, vehicle, ticket. Things you can point at later.
- 02
Name the verbs
Park, allocate, occupy, price, pay, exit. Do not hide them in process().
- 03
Give each verb a home
Spot protects occupancy. A strategy chooses. A policy prices. A store remembers.
- 04
Leave a seam
Pricing and allocation almost always change in the follow-up.
Two failures interviewers grade instantly
Pattern-first modeling
Strategy is how you vary allocation. It does not answer whether Floor, Lot, or a service should call it. Name the owner first. Then the pattern has a job.
One Manager that is the model
ParkingLotManager that parks, prices, persists, and notifies is not a domain. It is every leftover verb in one class. Split the verbs again. If a method would still make sense with only this object’s fields, it belongs on the object.
How this shows up in other rounds
Parking lot is the teaching problem because the nouns are physical. The same moves apply to Splitwise: User and Expense are entities, Money is a value, settlement is a service that spans two balances. Elevator has a car that owns a state machine, and a controller that assigns requests — not an ElevatorManager that is the building. Movie tickets have Show and Seat as entities, Money as a value, and booking as a use case that must not leak seat lists.
When you walk into a new problem, do not ask “which pattern is this?” Ask “what lasts, what happens, who is allowed to do it?” That is domain modeling. Patterns are how you vary a verb after it has a home. Read entity versus value object next if you are still storing tickets and rupees the same way. Then object relationships if you are drawing every arrow as “has-a.”