Chapter 5 - Event Sourced aggregates are hard to refactor

-

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 we are in front of the fourth villain of our story.

Aggregates, especially event-sourced ones, are hard to refactor!


Designing the right aggregates is difficult; it is easy to make modeling errors.
Furthermore, the requirements change over time, and the aggregates could need to be modified accordingly. Whatever the reason, solving a late-stage mismodeling problem can be very expensive.

In particular, by adopting event sourcing, we create a bond between the domain event and its aggregate.
Each domain event is part of one and only one aggregate.

Refactoring an aggregate may require a partial or full re-write of the event store. Many times, this is not so simple. It also happens that, to avoid facing a rewrite of the event store, one prefers to abandon the refactoring, accepting to live with the wrong choice initially made.

The story continues to the next chapter
Chapter 6 - The aggregate could cause unnecessary complexity

... or watch the full story on youtube

Location: Parma PR, Italia

Comments

  1. Andrzej LudwikowskiApril 14, 2023 at 1:12 PM

    I would argue that refactoring a non-event-sourced aggregate is even harder. Besides the code, there is usually a complex db schema migration required. It's hard to run the migration slowly and very often the stop-the-world point is mandatory to make the migration correct. Whereas with event sourcing an aggregate is just a projection from events. It is a very specific one because it is used for keeping the state correct, but still, just a projection. When working with event sourcing I feel more comfortable with the aggregate design because I can always replay events and create a different aggregate. Splitting the aggregate is a bit more sophisticated but, in general, easier than without event sourcing. Also, I can run the migration in parallel to the normal processing and do the quick switch when I'm ready.

    ReplyDelete

Post a Comment

Popular posts from this blog

Chapter 1 - I am here to kill the aggregate

-
Image
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...
Read more

Chapter 2 - The Aggregate does not fit the storytelling

-
Image
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...
Read more

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 ...
Read more