Domain Modelling

Domain modelling is the work of making your types and names match how the business actually thinks, so that reading the code teaches you the domain.

Ubiquitous language means one vocabulary shared by engineers and domain experts. If they say "policy" and the code says "contract", every conversation carries a translation step, and translation is where misunderstandings live. Rename the code.

Entity versus value object. An entity has identity that persists through change — a User is the same user after changing their email. A value object is defined entirely by its attributes: two Money objects of 10 GBP are interchangeable, and it should be immutable. Getting this backwards produces either identity bugs or pointless database rows.

An aggregate is a cluster of objects treated as one unit for changes, with a root that is the only entry point. An Order with its OrderLines is the standard example: you do not modify a line directly, you tell the Order. The point is that invariants — "an order's total must equal the sum of its lines" — have exactly one place they can be enforced.

Invariants are the heart of it. A rule that must always hold should be impossible to violate, not merely checked in the service layer. If an Order cannot exist without a customer, the constructor should require one rather than a validator flagging it later.

An anaemic domain model is classes of getters and setters with all the behaviour in service classes. It is not wrong so much as a missed opportunity: business rules end up scattered across services, so the same rule gets implemented twice, slightly differently.

A bounded context is where one model applies. "Customer" in billing and "Customer" in support are genuinely different things with different fields and rules, and forcing them into one shared class produces an object that serves neither. Draw the boundary and translate between them.