domain-driven-design

Bounded contexts partition your domain into explicit boundaries, each with its own ubiquitous language and model. Define context boundaries first, then design aggregates and entities within each context to enforce invariants and isolate concerns, reducing architectural complexity across your system.

Aggregates are clusters of entities and value objects treated as single units for consistency. Entities have unique identities and lifecycle; value objects represent concepts without identity. This distinction enforces invariant boundaries and persistence ignorance in your domain model.

Use domain events to communicate state changes between aggregates. Aggregates publish events when invariants change; other aggregates subscribe and react asynchronously, maintaining loose coupling while ensuring consistency across your bounded context or system.

Start with a modular monolith using bounded contexts as modules; this reduces deployment complexity while maintaining clear architectural boundaries. Migrate to microservices only when bounded contexts have distinct scaling, team, or deployment needs that justify the operational overhead.

Use event storming to map domain processes and identify natural boundaries. Define a ubiquitous language within each context, then start with one aggregate and a value object to establish patterns before expanding to the full model across contexts.

Persistence ignorance keeps domain logic independent of database implementation, allowing aggregates to focus on invariants and business rules. This separation enables domain models to evolve and be tested without coupling to storage technology or ORM frameworks.