Domain Model

A rigorous, selectively simplified model of a domain that is bound tightly to the code that implements it. In model-driven design the same concepts, names, and rules appear in the model, the team's language, and the running software. The model is not documentation produced once; it is the shared abstraction the code is organized around, refined continuously as understanding deepens.

Why it Matters

Domain software is hard because the domain itself is complex, not because of the technology. A model is how a team makes that essential complexity tractable, deciding what to represent and what to ignore. Binding the model to the code keeps the two from diverging, so the code stays a faithful, changeable expression of how the business actually works rather than drifting into incidental structure.

Signals

• Code structure and names mirror the domain concepts; a domain expert can recognize the business in the code's vocabulary.
• When the model improves, the code is refactored to match, rather than the insight being lost.
• Anti-signal: an anemic model that is just data, with the real logic scattered elsewhere.

Benefits

Essential complexity made tractable, code that communicates intent, and a model and implementation that evolve together instead of drifting apart.

Risks

A model kept in diagrams that the code ignores; an anemic model with behavior pushed into procedural services; over-modeling parts of the domain that do not differentiate the business, when the depth belongs on the core domain.

Tensions

A richer model captures more but costs more to build and learn, and fidelity to the domain competes with implementation constraints. The model is a deliberate simplification, so deciding what to leave out matters as much as what to include.

Examples

Modeling "interest accrual" as an explicit domain concept with its own rules rather than scattering the calculation across services; refactoring the code once the team realizes the real concept is "settlement," not "transfer."