The Aggregate is dead. Long live the Aggregate! - Sara Pellegrini & Milan Savić

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!