Sam Newman (2019), Monolith to Microservices, O′Reilly.
Eric Evans (2004), Domain-Driven Design Complexity in the Heart of Software, Addison-Wesley.
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.
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.
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.