Earlier this year, in may, I attended a 2 days conference about software craftsmanship in Paris: NCrafts. I also been able to attend a one day workshop about EventStorming.
This workshop was hosted by Alberto Brandolini and Mathias Verraes. Alberto is the founder of the Italian Domain-Driven Design (DDD) community, he runs Avanscoperta, a training company in Italy where he is a consultant as well. You can also encounter him as a speaker in various conferences across Europe. He is the one that came with the word “EventStorming”.
Mathias is an independent Belgian consultant focusing on software practices, on dealing with legacy systems and especially on DDD. Like Alberto you can meet him during conferences or during workshops, there is a list of all of his incoming ones on his personal website.
So you probably guess that EventStorming is about Domain-Driven Design and how to model it. I did this workshop because I consider that as professional software developers we have to understand the domain we work on in order to create the best possible applications.
Prerequisites
To practice EventStorming you need space on a wall, a lot of space. You also need sticky notes, a lot of them with different colors. You have to bring markers for everybody as well, the rule is at least one per person. Remove the tables and the chairs to be able to move freely in front of the wall.
Once the room is ready you need people with questions (the developers) and people with answers (domain experts, business analysts) in order to model the domain of the application.
An events driven approach
Everyone is ready, they have sticky notes and a marker, time to ask the first question: What is the most important event in the system? (from a domain point of view). In other words: what is the goal of the entire application? If the team works on a project without knowing what the main goal is, they will probably end-up with a “not so good” product.
Once you know the Event, write it on a sticky note (orange one) and put it on the wall. Most of the time the event are written using participle past phrases (InvoicePaid, UserRegistered, …). Now it’s time to model around this main event by turning back time: What is the event that occurred before? And before that?
The goal is to find the entire event chain that leads to the main event, this will give you a good idea of what is happening in the system from a business perspective. You will create something like the following picture (this is just a small example):
If you are not sure about the necessity of an event, you can ask the domain experts if they care about the event or not, they know if it is relevant or not. For instance a “ButtonClicked” event is probably not relevant from a business point of view, except if the domain you work for is about buttons being clicked. Focus only on domain events, not on technical ones.
Linking the events
Now you have your events chain, the work is far from over, you need to add the “links” between them. An application cannot just be a succession of events. What happened between an event and the one before? What kind of action is required? For example, what happened between “InvoiceSent” and “InvoicePaid”? The client has to pay the invoice!
This last sentence looks obvious but it contains two important components for the EventStorming approach. The first one is the Command: “pay the invoice”, this is the action that has to be done. Time to change the color of your sticky notes, take a blue and write the command on it (Pay invoice) and put it between the two events.
Sometimes when you think of the command needed for an event to occur you might discover that there are more events in the system than you initially thought about or some are missing. If so add them on the wall where they belong, you can add new events at any time.
In “the client has to pay the invoice” there is another valuable information: the Actor, the person/system that acts on the application and launch the command. In this case the client is the actor, put a yellow sticky with the note “Client” on the command post-it.
Now you have a more detailed version of the domain, something like on the following picture.
One last thing regarding the commands, their execution can produce several events, it is not something to avoid, it all depends on your business domain.
And actors can be external to the system, in this case you can use a different color of post-it (pink) in order to identify them quickly.
Adding more information
Producing an event is the work of a command, yet the output of a command is not necessarily always the same, it depends on the Business Rules. For example, given a scenario where a user wants to log in, the expected event is UserLoggedIn. But what should happen if the username and the password are incorrect? We definitely don’t want the user to be logged in the application, in this case the “Log in” command has the following business rule: username is known and password is correct for the given username.
The business rules can be written on another kind of sticky notes (big and yellow) when the rules are quite specific, not like in the example I gave. Otherwise you will pollute the wall with irrelevant post-its containing obvious information.
To apply the business rules, a command needs information to know what it should do. In the log-in example this information is the username and the password. It is called the Message and it holds the data for the system.
Use a post-it (green) to list the data needed by the command and put it beside the related business rule/command couple. This way you are able to see where are the commands with complex business rules and what are the data needed.
After all of this you will have something like this:
As you can see, you really need a lot of space and you quickly locate every type of notes. And on this picture the entire model was not complete even after an entire day.
Do not be frightened by the time it took, you are not forced to model the entire application in a row, do it step by step, start with a single sub-domain. You will add the others during the next EventStorming sessions using the base you have already created.
Conclusion
I really enjoyed this workshop, I liked the collaborative approach of the EventStorming, everyone can be involved. It gives a very good representation of the business domain, what it should do and how.
Since the exercise is done with domain experts they use domain terms and therefore you are able to extract the ubiquitous language from the EventStorming session.
The format also favors story telling which are very helpful to gain knowledge of the business domain (“Most of the time it works that way but on rare occasion it works differently like this time when…”).
To summarize: An Event is the result of a Command, triggered by an Actor, following a set of Business Rules using the data of a Message.
A big thanks to Alberto and Mathias for making this workshop an awesome experience, do not hesitate to check their works on the topic, there is plenty of information they can teach you about EventStorming.
See you next time!
And here are some more pictures.
Coding Journeyman 