Domain Modeling

Entity — identity that survives change

An Entity is a thing you track as itself over time. It has a distinct identity — usually an ID — that stays the same even as every other attribute changes. Order #4471 is the same order whether it's pending, paid, or shipped; the customer renaming themselves doesn't make them a different Customer. The defining test: two Entities with identical fields are still two different things. Two brand-new orders that happen to have the same items and total are not the same order — they have different IDs. So Entity equality is by identity, not by value: a.equals(b) means a.id === b.id.

Entities also have a lifecycle — they're created, they change state, they may eventually be archived or deleted — and the model is usually responsible for protecting the rules of that lifecycle (you can't ship an unpaid order). Typical entities: Order, Customer, Product, Account.

Value Object — defined entirely by its attributes

A Value Object has no identity — it's defined completely by its attributes, and two value objects with equal attributes are interchangeable. Money is the classic example: two separate $5 notes are equal; you'd never ask "but which $5 is it?" The same goes for an Address, a DateRange, a Color, an EmailAddress. Because they have no identity, value objects should be immutable: once created they never change. Need a different amount? You don't mutate the Money — you create a new one. This is exactly the immutability you learned earlier, and the reason value objects must override equals/hashCode to compare by value, not by reference.

Service — behavior with no natural home

Sometimes an operation involves several objects and doesn't belong to any single one. Transferring money touches two accounts; computing tax depends on jurisdiction rules, not on the order alone. Forcing that logic onto one entity makes it awkward ("why does Account know how to debit another account?"). A Service is the home for such behavior: a stateless object named after a verb — TransferService, TaxCalculator, PaymentService, PricingService. Stateless is the key word: a service holds no domain data of its own; it operates on entities and value objects passed to it. If you find yourself adding fields to a service, it probably wanted to be an entity.

Aggregate — a consistency boundary with one root

Real domains have clusters of objects that only make sense together. An Order owns its OrderLines — a line item has no independent life outside its order. An Aggregate is such a cluster, treated as one unit for consistency, with a single aggregate root as the only entry point. Outside code talks to the Order; it never reaches in and grabs an OrderLine directly. The root enforces the invariants of the whole cluster — "order total equals the sum of its lines," "a shipped order can't add lines" — so the rules can never be broken from the outside. Add a line by calling order.addLine(...), and the Order (the root) keeps everything consistent.

A pure domain layer — no persistence or UI inside

The model stays valuable only if it stays pure: a domain object should be about the business, not about SQL, HTTP, or React. Keep database mapping, JSON serialization, and screen layout out of the model and in the layers around it (repositories, controllers, views). When the domain layer has no idea a database exists, you can test the business rules in milliseconds, swap the storage engine without touching the model, and read the code as a description of the domain rather than a tangle of framework calls.

// ENTITY: identity-based equality — same id ⇒ same Order
class Order {
  constructor(public readonly id: string) {}   // identity persists through change
  equals(other: Order) { return other instanceof Order && other.id === this.id; }
}
const a = new Order("ord-1");
const b = new Order("ord-1");
a.equals(b);                 // true  — same identity, even if state differs

// VALUE OBJECT: value-based equality, immutable — no identity at all
class Money {
  constructor(readonly amount: number, readonly currency: string) {}  // frozen
  equals(o: Money) { return o.amount === this.amount && o.currency === this.currency; }
  add(o: Money) { return new Money(this.amount + o.amount, this.currency); } // returns NEW
}
new Money(5, "USD").equals(new Money(5, "USD"));   // true — two $5 are interchangeable

When a domain model earns its keep

Reach for a rich domain model when the business logic is the hard part — interesting rules, invariants, state transitions, and money. That's where entities-with-behavior, immutable value objects, and aggregate roots that protect their invariants pay off, and where speaking the ubiquitous language keeps engineers and domain experts in sync. Start the design by listing the nouns of the domain and classifying each as Entity, Value Object, or Service — exactly the drill in the prototype.

When the app is mostly CRUD over forms with little real logic, a heavyweight model is overkill — a thin data layer is fine, and forcing DDD machinery onto it just adds ceremony. The judgment call is how much logic is there, and how often does it change? The more the rules churn, the more a clear model with behavior-on-the-objects repays the effort.