← Back to principles

Data

Model the domain, not the database

Statement

Data exists to serve the domain and businesses should not have to fit around data models

What this means in practice

Data models are shaped by the business domain they represent, not the other way around. If a business expert does not recognise the meaning of a data field, it does not belong in the model. The language used in the domain -- the terms, relationships, and rules that business stakeholders understand -- should be directly reflected in how data is structured, named, and related. Technical convenience does not override domain clarity.

The domain is responsible for its own rules and invariants. Business logic and data integrity enforcement belong in the domain layer, not buried in database constraints or stored procedures where they become invisible to the teams building and maintaining the product.

Why this matters

When data models drift from the domain they serve, the gap between what the business needs and what the system delivers widens. Teams spend increasing effort translating between technical structures and business concepts, introducing errors and slowing delivery. Anchoring data models to the domain keeps systems comprehensible, reduces miscommunication, and ensures that the data accurately represents the reality it is meant to capture.

Pushing integrity rules into the database layer fragments business logic across tiers, making it harder to test, harder to reason about, and harder to change as the domain evolves.

Practices that meet this principle

  • Use domain language consistently in data models, schemas, and API contracts

  • Involve domain experts in data modelling decisions and reviews

  • Enforce business rules and invariants in the domain layer rather than solely through database constraints

  • Challenge any data field or relationship that cannot be explained in business terms

  • Refactor data models when they no longer reflect the current understanding of the domain

  • Document the mapping between domain concepts and their data representations

  • Database structure is not directly exposed through the endpoints

Validation

A project meets this principle when:

  • Data model entities and fields use terminology recognised by business stakeholders

  • Business rules are enforced in the domain layer with clear test coverage

  • OR:

  • Changes to the domain model are reflected in the data model within the same delivery cycle