All Articles

Just enough Domain-Driven Design

Sam Newman (2019), Monolith to Microservices, O′Reilly.

Eric Evans (2004), Domain-Driven Design Complexity in the Heart of Software, Addison-Wesley.

Just enough Domain-Driven Design

Modeling services around a business domain has significant advantages for a microservice architecture. Eric Evans (2004) presented a serie of ideas that help represent the problem domain.


In DDD, an aggregate is a representation of a real domain concept, e.g an Order, Invoice, Stock Item, etc. Aggregates typically have a lify cycle around them, which opens them up to being implemented as a state machine. We want to treat aggregates as self-contained units. We want to ensure that the code that handles the state transitions of an aggregate are grouped together, along with the state itself.

A single microservice will handle the life cycle and data storage of one or more different type of aggregates. If a functonality in another service wants to change one of these aggregates, it needs to either directly request a change in that aggregate, or else have the aggregate itself react to other things in the system to initiate its own state transitions.

Bounded Context

A bounded context typically represents a larger organizational boundary inside an organization. Bounded contexts hide implementation details. Bounded contexts contain one or more aggregates. Some aggregates maay be exposed outside the bounded context; others may be hidden internally.

Mapping aggregates and bounded contexts to microservices

Both the aggregate and the bounded context give us units of cohesion with well defined interfaces with the wider system.

  • an Aggregate is a self-contained state machine that focuses on a single domain concept
  • a Bounded Conntext is a collection of associated aggregates with an explicit interface to the wide world.

Both can work well as service boundaries.