This is the 5th post in a series about how to use Event Storming to kick start architecture on good tracks. If you want to understand the full story, I recommend you to start reading from the beginning.
In the 2 previous posts (3rd and 4th), I went over all the preparation to do before the workshop. Let’s move into the real thing. Now that we have everything ready, how do we actually run this workshop?
1. Prepare the room
I learned from experience that I to come in the room around 30 minutes in advance to prepare it for the workshop. Previous post has all the room preparation details. Roughly, this includes:
- Removing tables and chairs
- Sticking the design-space to the wall
- Sticking the Visual Agenda to the wall
- Laying down the rest of the material somewhere
As I’ve already said, DDD Event Storming is a different kind of architecture meeting. It won’t work if people don’t get out of their traditional way. Running a physical energizer with everyone is great for that.
It’s also very useful to raise the energy level. Event Storming can be pretty intense and tiring, so they’ll need all the energy they can. You can find many great physical energizers at funretrospectives.com. I’ve had success with many of them.
3. Briefing and Agenda
Now is the time to present the workshop. Start with the goal, scope and use cases. It’s the good moment to explain each step we will go through, and how they will help us to reach our end goal. It’s also a good time to introduce some general conventions. Here is a typical brief I could say.
Remember that DDD Event Storming is a way to shrink months of Big Design Up Front into a few days! It’s going to be intense, but we’ll do a lot in a very short time.
Event Storming might be chaotic. It might be rocky and go in unexpected ways at times, we might need to adjust. 💡 At the end of the day though, the success is all up to how much you want it!
The main outcome of this workshop is the shared knowledge between domain experts and developers. We’ll later build on this shared knowledge to get
We must stick to domain language if we want to keep this collaboration alive. 💡 I’ve seen Event Storming sessions drifting into technical discussions, this leads nowhere.
Scope and use cases
Today, we’ll work in the scope of <your scope>. To make things a bit more concrete, we’ll start with these use cases in mind <list your use cases>. We’ll be modeling around domain events such as <your 1st event>.
A quick brief about post-it colors.
You could read about them in domain books
Domain experts understand them
Writing them in past tense is a trick to create meaningful events. They are not actions of someone or something (not “The trader books the deal”). Even though some events will result from actions, we are not interested in actions yet.
They are not technical, and should not be specific to our system’s implementation
Domain Definitions (aka Ubiquitous Language)
Whenever we come across or agree on a domain word, feel free to write a definition for it on a large yellow post-it. This is a way to build up a domain ubiquitous language. This is very helpful to improve the communication between all of us. This in turn improves how we work in many different aspects (ex: when choosing what to refactor).
Likewise, we use purple post-its to park “problems”. Whenever we encounter:
- a question we cannot answer
- something that does not seem right
- or any problem we should look into
Record it on a purple post-it.
Finally, to keep the pace sustainable, we’ll take a 5 minutes break every 50 minutes.
Once this general speech is over, I usually quickly present every steps of the agenda.
To be continued
This only covers the first half of the workshop. In next post, we’ll go over the following steps.
This was the 5th post in a series about how to use Event Storming to kick start architecture on good tracks.