Member-only story
Why Your Microservices Architecture Needs Aggregates
What are Aggregates and how can they help you in the long run?
Microservices are all about organizing our stuff into discreet, well-defined units.
Whereas our legacy monolithic generally meant that every engineer in the organization worked on every part of the application, and every business entity had a tight coupling with every other entity, microservices allow us to move in a different direction.
Engineering teams should focus exclusively on their own business domains. And business entities should be coupled only with other entities in the same domain.
Drawing these boundaries, however, is easier said than done. So, new patterns have emerged, and older ones rediscovered. The bounded context, for example, is a recently-popularized pattern that guides us in organizing our engineering teams and business domains at a high-level.
Likewise, the Aggregate pattern is one that helps us to organize our data at a lower level. This pattern was initially defined as a way to transactionally group changes to related entities.
It has also come to provide us with a blueprint for breaking apart our monolithic data schema, essentially grouping highly cohesive entities into a single, atomic unit.
And its benefits go way beyond that.
Interestingly, the Aggregate pattern doesn’t seem to be as well-known, widely-discussed, or commonly-implemented as other distributed software design patterns. But I’ve found it to be a fundamental building block when constructing microservices.
Designing with Aggregates upfront helps us to avoid the sorts of things, such as accidental dependencies or leaky references between entities, that typically dog us as we try to scale.
First, let’s look at what Aggregates are.
Aggregates
The Aggregate is a design pattern popularized by Eric Evans in his tome Domain-Driven Design, a book that, while not explicitly written to discuss microservice architectures or distributed systems, has nonetheless emerged as a guide on those topics.
