Chapter 7 - Focus on the behavior

-

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 able to retrieve all the information needed to make a decision. 
On the other side, the software component, triggered by a certain situation, should be able to load all information needed to make a decision. Exactly as the person does.


The focus here is on the behavior, not the model.
The decision block exists because the system needs to react to a certain trigger.
It is the behavior that determines the need to have that decision block.

The focus is on the software component that reacts to a trigger. The trigger could be a command, and then the decision block could be called "command handler". The trigger could also be an event, and then the decision block could be called "event handler". It does not really matter, more generally we can call it "message handler".

The important bit here is that the decision block is able to load the model needed to do its job.

At this point, event sourcing comes to our aid, because provides the huge advantage of decoupling the persistence from the model needed for making a decision. 

The story continues to the next chapter

... or watch the full story on youtube

Comments

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 business rul
Read more

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