Posts

In Praise Of Event Sourcing

Image
A few days ago, at Brussels station, Milan and I engaged in an exciting discussion about interpreting the question: "What are the benefits of a given solution?" During the conversation, I contended that the answer should only include the benefits directly arising from utilizing that particular solution. In my opinion, the question was equivalent to asking: "Why should I adopt that solution?" On the contrary, Milan argued that all the positive aspects resulting from the solution, even those indirectly related to the solution itself but stemming from the prerequisites it entails, should be listed as benefits. We were so engrossed in grappling with this little dilemma that I nearly missed my train. This entire discourse originated from a question we received the day before at Voxxed Days Brussels: "What are the benefits of event sourcing?" To provide an answer to this question, we must first clarify what we mean by event sourcing. Over the years, I've ob

A name for an idea: Dynamic Consistency Boundary

Image
Sometimes the best way to promote your idea is to give it a proper name. That's what some weeks ago, @nicolaibaaring suggested I do. Interesting concept. 😃 I have had a lot of these thoughts myself. I feel this concept should have a name of its own to make it easier to communicate and define. Maybe something was mentioned in the talk that I didn't get. Do you have anything in mind? 🤔 — Nicolai Baaring (@nicolaibaaring) April 8, 2023 After some time needed to find the best name for the concept, here we are, finally, talking about Dynamic Consistency Boundary! - thank @RobertBaelde , for your suggestion - Maybe something in the direction of multi-stream event sourcing? Or dynamic consistency boundaries? Also get a sense of event sourced transaction script with this concept, but that might not be the direction you want to go in — Robert Baelde (@RobertBaelde) April 9, 2023 I want to use this blog post to summarize, in easy terms, what Dynamic Consistency

Chapter 10 - The Aggregate is dead

Image
continues from  Chapter 9 - An event is just a fact, pure ...... The aggregate is finally dead, together with its negative aspects. This new approach, which focuses on the decision block, has several benefits: Perfect match with storytelling Focus on behavior instead of model Less contention Less complexity  Simpler to refactor But be careful: this does not mean having to organize the system in order to have hundreds of completely unrelated command handlers. Absolutely not! Clustering commands into logical groups and delegating their execution to the same model is and remains a correct programming approach. The difference lies in the fact that before, by the very definition of aggregate, these models necessarily had to be isolated from each other. Killing the aggregate means admitting the possibility of contamination between these models without renouncing consistency. A less dogmatic approach, which in any case must not disregard good programming practices, but which, thanks to greate

Chapter 9 - An Event is just a fact, pure

Image
continues from  Chapter 8 - The Death of the Aggregate ....... Surely you remember that, in modeling the Student aggregate and the Course aggregate, we defined some events that looked like duplicates: They were necessary to validate the respective invariants of the course and the student during the subscription process. If we had a weird feeling during the event storming phase, the feeling doesn't improve later. Indeed, reading the content of the event store, we can notice that for each subscription, there are two close events with the exact same content! They differ only because they originate from one or another aggregate (represented here by the colors red and green). How can we get rid of this? In reality, the domain event is only one: its duplication is functional to the existence of the two aggregates.  But if we get rid of the aggregate, then as a direct consequence, we might also get rid of the duplication of these events. Indeed, if we get rid of the aggregate, then an eve

Chapter 8 - The death of the aggregate

Image
continues from  Chapter 7 - Focus on the behavior ...... Event sourcing provides a huge advantage, because it decouples the persistence from the model needed for making a decision. Any message handler can build, on the fly , any model needed for making a decision, starting from the correct event stream. Let's make a practical example to understand better. Assume we need to handle the UpdateCourseCapacity Command .  This is a representation of the Event Store, where the events belonging to the course aggregate are highlighted in green. If we decide to use the classic aggregate approach, we need to reconstruct the Course aggregate starting from the stream of its events. Let's take a different approach instead, where the command handler is responsible for retrieving the model needed to make a choice. We immediately realize that not all the events that are part of the Course Aggregate contain information useful for our purpose. For example, the fact that the course has been rename

Chapter 7 - Focus on the behavior

Image
continues from  Chapter 6 - The aggregate could cause unnecessary complexity ...... Can we happily live without aggregates? I think we can! Since it is difficult to design the right aggregates, I asked myself: can we guarantee consistency in another way? In a more flexible and less constraining way than the aggregate one? The secret, from my point of view, is to focus on the behavior, not on the model. We want to go back to the fluidity, the naturalness, and the beauty of storytelling. Imagine simplifying the system as much as possible, until it is nothing more than a series of actions and reactions. The causal link between them is represented by a decision, taken on the basis of one or more business rules. This is precisely the atomic element we need, the block that connects a specific trigger to its consequences . We could compare this chain of actions and reactions to a game of ping pong between a person and the system. On one side, the person, triggered by a certain situation,  is

Chapter 6 - The aggregate could cause unnecessary complexity

Image
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 new aggregate: the stu