Event Thinking

continues from  Chapter 5 - Event sourced aggregates are hard to refactor ...... Let's add a little more spice to our example, introducing rule number 4: A course cannot accept more than N students N, the Course Capacity, can change at any time to any positive integer different from the current one (even if the number of currently subscribed students is larger than the new value) The course title can change at any time to any title different from the current one The student cannot join more than 10 courses Back to the board! We need a new event for the creation of the student, and the relative command. But here, things get complicated, since we need a new event for the subscription and a new event for the unsubscription. Both triggered by their respective commands. Déjà-vu? Yes, because we have already met very similar events and commands when we were talking about the course.  But now we need two more pairs, because the newly introduced rule is relative to a ne...

continues from  Chapter 4 - The larger the Aggregate, the greater the contention ...... What if we realize only in an advanced stage of development that we have modeled the aggregate incorrectly? Of course, it depends! If we are using State Persisted Aggregates, we could transform the aggregates with some scripts. If we are using Event Sourced Aggregates, the situation gets complicated. This is the representation of an event store; the highlighted events belong to a specific instance of the Course aggregate.  If we decide to refactor this aggregate, replacing it with the CourseSubscription and CourseInfo aggregates, we need to rewrite the event store. The course creation event is replaced by two events for the creation of the two new aggregates: CourseSubscription and CourseInfo. The other events belonging to the Course aggregate are replaced by events belonging to the CourseInfo or the CourseSubscription aggregates. The color represents the new aggregate instance. Here w...

continues from  Chapter 3 - The aggregate mixes technical and business aspects ...... Let's add something new to our example, introducing rule number 3: A course cannot accept more than N students N, the Course Capacity, can change at any time to any positive integer different from the current one (even if the number of currently subscribed students is larger than the new value) The course title can change at any time to any title different from the current one We need to introduce a new event, to represent the fact that the course has been renamed. And a new command to request the change of the Course's title. Who should this command be sent to? The most common answer is: " to the Course ". The Course aggregate is now responsible for something more than before. It may seem irrelevant, but it hides a pitfall. Let me introduce you to the third villain in our story: The larger the Aggregate, the greater the contention! The natural attitude to choose as aggregates the bu...

continues from  Chapter 2 - The Aggregate does not fit the story telling ...... Let me introduce villain number 2. The aggregate mixes technical and business aspects. For some reason, consciously or not, we try to bring together, in the aggregate, two different models: the model to guarantee the invariants our mental model of the domain concept Although this may seem natural, often, these two models do not coincide. Strong consistency constraints do not always reside within the same business concept. It may happen that there are consistency constraints in the intermediate area between two or more business concepts. For some people, this difference between the domain concept and the consistency boundary is crystal clear. I was positively impressed by the technique used by my friend Mauro Servienti to model the aggregates. He takes a reverse approach, first grouping data that share consistency constraints, bringing together information that changes together or whose change is de...

continues from   Chapter 1 - I am here to kill the aggregate ...... One of the most powerful elements of DDD is that it has broken down the barriers between technicians and domain experts, thanks to tools capable of exploiting the immense potential of storytelling, first of all Event Storming. Storytelling is at the heart of human communication. Storytelling does not require any special competence or skill. It helps break down the barriers between technicians and business experts. In my experience, the usage of storytelling ensures an exceptional fluidity in the domain discovery process, but it hits a snag when we try to introduce the aggregate into the story. Indeed, by definition, the aggregate is the boundary of consistency. The aggregate is the component responsible for ensuring strong consistency constraints within an ecosystem that is, by nature, eventually consistent. But, at the same time, it tries to represent the business entity acting as the guardian of a set of bus...

The aggregate has always been, for me, one of the most controversial and weakest elements of Domain Driven Design. During my consultancy activity, I have been able to verify that the full understanding of the aggregate concept remains difficult for many. It is easy to make mistakes in the modeling phase, which will be very complex to fix in more advanced stages of development. As a result, some developers feel that the whole architecture is excessively difficult and complicated. I want to show you another world, where there is no aggregate. I am here to kill the aggregate. For those unfamiliar with it, let me introduce it to you. The Aggregate Its definition is, in my opinion, is quite vague: An aggregate is a cluster of associated objects  that we treat as a unit for the purpose of data changes. From blue book - Domain-Driven Design: Tackling Complexity in the Heart of Software - Eric Evans If you are confused by this definition, let's try to read what the blue book recommends for...