DDD FR

 
 
 

DDD's definition of Aggregate may seem somewhat confusing - "An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes." Okay, let's try to clarify - "You should consider your aggregate as a unit of consistency in your Domain.". That doesn't help either.

As a matter of fact, while modeling our systems, we tend to group together events related to the same domain concept; we tend to define groups based on the nouns we find inside our events’ name: saying "this is our aggregate!".

According to the aggregate definition, we should instead ignore these nouns, and put together the data that change together.

Easier said than done: in the modeling phase it is easy to make mistakes trying to identify the boundaries of our aggregates based on this rule.
If we opt for saving the state of our aggregate as a series of events, we are in big trouble - any (serious) refactoring of the aggregate structure becomes close to impossible. The reason for this trouble is that we have to make a decision in the design phase for which we cannot be lenient. We are basically married to this decision forever.

Due to the aforementioned reasons (and many others), people struggle with the Aggregate pattern. Some even say it is unnecessary, we are one of those.

Let's see whether we can model our business constraints without aggregates. Could we be more relaxed when consistency is in question? Join us to discover how!

—-

Sara Pellegrini is an enthusiastic and proactive IT professional who specializes in distributed architectures with experience in agile software development methods. Able to see things from a different perspective, with an all-around approach to software development, from coding skills to high-level architectural view. Since she joined AxonIQ, she focuses on Axon Server and Axon Framework development.

Milan Savić is Software Engineer at AxonIQ. Milan has experience with various software projects ranging from chemical analyzers to contactless mobile payment systems. In some of those projects, CQRS and Event Sourcing came as a natural solution, but things had to be built from scratch almost every time. Finding out about Axon Framework got him interested in being a part of the solution. In March 2018 he joined AxonIQ team on a mission to build tools which will help others in building event-driven, reactive systems.