Implementing Domain Models: Layers, Aggregates, and Bounded Contexts

A domain model is not implemented just because a project has entity classes. The real questions are where rules live, where transaction boundaries are, and how contexts collaborate.

Background

Many projects have a Domain layer, but rules are scattered across controllers, services, SQL, and frontend validation. Any rule change then requires searching through multiple places.

Core Concepts

Layers define responsibilities. Aggregates define consistency boundaries. Bounded contexts define semantic boundaries.

flowchart TB
    A["Interface layer"] --> B["Application layer"]
    B --> C["Domain layer"]
    C --> D["Aggregate / Value object / Domain service"]
    B --> E["Infrastructure layer"]
    E --> F["Database / Messaging / External services"]

Engineering Scenario

In an approval system, whether a request can be submitted depends on state, requester permission, amount threshold, and workflow configuration. That rule belongs in the domain model, not scattered across API handlers.

Common Mistakes

• Designing aggregates too large.
• Modeling objects only from database foreign keys.
• Leaving domain objects as getters and setters while services hold all business logic.

Best Practices

• Use aggregates only for rules that require strong consistency.
• Coordinate across aggregates through application services or events.
• Name domain methods with business language.
• Allow each context to own its model.