A useful introduction
As I’ve announced in the previous post about the benefits we’re gaining from the Event storming, now it is the perfect time to talk about the agenda of this approach, as well as some practical tips from my experience so far.
A little reminder: event storming sessions are used as a means for business process modeling and requirements engineering. Don’t consider it as a replacement for design document, flowchart, UML diagram or anything similar.
You can read my introductory post here.
There are some key terms that I’ll explain before proceeding further. The first one is domain event. As a term of two words, it covers anything that happens and it is of interest to the business model of the customer (client). Here comes the second key term – domain expert. This person is not interested in databases or design patterns. Instead, domain experts are all about the business domain of the things that have to happen.
The process
Developing a software requires keeping track of all the things you need to plan for which is often hard. Not to mention how complicated this process can be when you start something from scratch. You’ll have to keep analyzing and planning how all the moving parts will interact with each other.
Event storming explains and discuss the flow of the events in an organization. Then, as a software engineer you are able to model that flow in an easy and understandable way.
This collaborative activity brings together domain experts and technical architects and all related parties responsible for system development to discover and set an ubiquitous language of a system under development.
What do you need?
There are numerous factors for making the workshop as effective as possible. I’ll start with the most important ones.
The people
The people are at the very core of having a successful workshop. You need to invite the right people. The key is to invite everyone that will potentially develop the product/service as well as all the business experts – the ones that know the domain very well. Make sure to bring these types of people in one place:
Those who ask the questions
Those who have all the answers
The guiding facilitator
Consequently, software engineers are eager for answers. The domain experts know how to answer their queries.
The facilitator is here to guide the group when domain events emerge.
The place
When it comes to the ingredients for organizing an Event storming there are several must-have things in the defined spot.
The most required part of this practice is having an unlimited modeling space. It may be a very long piece of paper or a wide wall for placing the stickers. At our company, we have wide glass wall which showed as a perfect place for placing all the countless sticky notes.
In addition, you will need a lot of sticky notes and in as many colors as possible. Along this, provide many marker pens and some masking tape.
Having a pleasant and relaxed atmosphere is crucial! Practicing the Event storming in our offices showed us that no chairs are welcomed into the room. Make sure everyone is standing and actively participating in the workshop.
Event storming going live!
When everything is in place, the actual event storming starts when the first sticky note (a domain event) is placed on the wall. The discussion starts right after this moment.
Phase 1: First events first
As facilitator, I write the very first post and initiate the conversation to examine all the possible domain events. Everyone is focused on answering the question: what happened? At this moment, the group walks backward and forward around the model to discover and explore all the significant events that happened in the model.
Write down the events on orange sticky notes. Also, noting the events in past tense will help the group to focus on the aspect of “what happened?” not of “what will happen if?”. In my experience as facilitator, I advise you to keep the participants focused on domain events and not the actors performing those events. That process happens in the second step.
Don’t get upset if you end up with duplicates, you can group them later, and in fact, having duplicate events indicate that the events are important.
Phase 2: Trigger the commands
By the time the team moves to the second phase, the participants have a clear overview of most of the domain events. It is time now to find the answers for: why did this happen? The answers come as a result of commands and triggers that caused the discovered events.
The group directs into finding the origin of the events. Some of them are a direct consequence of a user action and some of them are triggered by other factors instead. Those factors include http calls, console commands and other external triggers. Save the blue sticky notes for these commands and place them before the corresponding event’s orange note.
This Event storming point is more time-consuming than the first stage. The reason is that people are starting to “storm” more questions and think what should happen which reflects adding new events.
Phase 3: Group the aggregates
When having all the commands and events in place, the participants are ready to group them into aggregates. Basically, aggregates represent a specific business concept. Subsequently, the people are starting to identify aggregates and group them into bounded contexts. Every context has clear limits and own rules. Moreover, it’s still connected and communicate with the other contexts.
Dedicate more time while being at this stage. Here comes the point when the ubiquitous language starts to become a foundation between all the people involved in the project. Leave some space for discussions as this final phase is the most difficult to understand for all the attendees.
The final output of this stage is a context map. Your model is ready and you can transfer into code to validate the group learning and verify the model.
Key Takeaways
As I’ve been practicing this approach so far, I must admit that the greatest effectiveness lies in its ability to get tons of useful work done in parallel for a short period of time.
Among the other advantages which I’ve talked about previously, there are other highlighted takeaways which are worth mentioning. One thing is certain: all of the participants get rich and big picture of the domain in which the software is supposed to operate.
This kind of workshop will save you resources and precious time before diving into implementation. Due to its format, as a software architect I am able to spot plenty of potential issues in logical, functional and business terms. Thus, these issues can be fixed in the early stages before putting crucial effort to them.
On the other hand, I’m receiving positive client’s feedback related to the Event storming sessions we had when starting the project. They all agree this practice helps them in visualizing their business and they are able to spot hidden points and relationships between departments they’ve never captured before.
Epilogue
Capturing a system in terms of events is a powerful way to merge design and domain thinking. Sharing the knowledge between us, as software engineers, as business people or as domain experts definitely helps building better software together.
I totally embrace you to give Event Storming a try next time when starting a software project. Feel the advantages of your own and you’ll never ever start a project without having Event Storming in the first place.
Have you ever experienced Event storming? Let’s have a discussion!
Till next time,