Modeling your Domain with Event Storming workshop
Event Storming is a technique that helps us to see our business from another optical. Well, I want to say that Event Storming shows us a map that contains: product intents, their comportments, and how the interactions occur… all of this in our software.
So, I think you understand a little, right? Don’t worry, we’ll talk more about it in this article.
Continuing… why do I talk about Event Storming? First, because I believe that the best way to build and model a software/product is by following the DDD (Domain-Driven Design) philosophy; and second, because I think that DDD and Event Storming fit perfectly.
Let’s Start!
In a few words, Event Storming helps us to map the actions that occur in our software, including which side effects these actions produce. And, consequently, these side effects may trigger other actions. So, we’ll build a flow, that helps us to see the boundaries of business intentions, what kind of intentions we have, and more.
The image below is an example of Event Storming output:
Let’s explain this image:
- 🟡 Yellow cards:
To start a flow/journey in our system we need some sensibilization, which is triggered by some users or other external systems. This sensibilization occurs externally. So, to represent it we use this card type named “Actors”. - 🔵 Blue cards:
When the actor uses our system he triggers some actions, like making a login, or buying a shirt in an e-commerce system. So, to represent this comportment, we use this card type named “Commands”. - 👛Light Pink or Light Yellow cards:
When actions/commands are triggered, these commands will enter our system/domain, causing some sensibilization. To represent this behavior/domain we use this card type and we named it “System” or “Aggregate”. - 🟠 Orange cards:
Pause for this card!⚠️ As I said before, the commands will enter our system, right? So, when this happens, these actions will generate some side effects which are the most important thing that we need to map, because this show us that our system did something, something changed… So, when something (command) happens, our system runs some comportment, i.e. it execute a specific situation that exists in our business rules, our domain, and then a side effect will be generated. So, this type of card represent these side effects, and we name it “Events”. - 🟣 Purple cards:
After these events occurred, they may trigger other specific commands. For it, we have some rules to decide it. So, these rules are represented by this card named “Policy”. - 🟢 Green cards:
Beyond policy, after the events occurred, they may sensibilize a UI either. So, something happened and whoever started the journey may know what happened, e.g. see some data modified. To represent it, we use this card named “View”, “Projection” or “Read Model”. - 🔴 Pink/red cards:
When we have doubts about some behaviors in our journey, we can pin an alert flag and postpone them. To represent it we use the card type named “Hotspot”.It’s important to solve these doubts at some point.
That’s it, now we know more about Event Storming. But running an Event Storming session may have its difficulties like: not all participants will be kept engaged, sometimes may be boring, not everyone will know what they want from the product… and, explaining how Event Storming works may be confusing at the beginning and achieving this flow draw may be complex and difficult, but it’s worth it! Let’s talk about the workshop!
The Workshop
Exists many other techniques to do this workshop, but in this particular session, I’m going to talk step-by-step about an experience that works for me.
- Instead of running it with many people, from different areas, try to make a short group with people of the same area, including stakeholder, tech people, and managers.
- When you gather this short group, do an overview about the Event Storming, show the goals, the advantages, and the difficulties that may occur .
- From here, I think that we have a key to running it successfully:
3.1. Instead of trying to start to draw the flow, propose to your group to brainstorm the commands/actions that may occur in the system/product. For non-technical people is easier thinking about the actions, as many of they start from a user and tend not to be a technical biased, than about the flow itself. Below you can see an example:
3.2. After you have mapped your commands, you can order them chronological. This will help you to see where would start and end the flow:
Note that, in this example after we ordered the commands, we have two paths. It means that looks like we can have two different flows/journeys in this case (although we thought that it was just one).
3.3. Finally, we can adjust these commands and use all other Event Storming cards type to fill the flow. Take this this moment to explain more about the Event Storming, specially the cards meaning and importance, and to envolve more the group to help you to build the flow:
Look that we have two different contexts. This happens because after we mapped the commands, we identified two flows. It’s a strong signal that may be different things, but it’s not a sure think. Only after discussing it in the Event Storming session we agreed that made more sense segregated into two contexts.
So, that’s how we can map our journeys!
PS: This Event Storming is a reference to the Aurora Project
Domain-Driven Design & Event Storming
Why is this a perfect match?
DDD shows us how we can build better products, for that we need:
- Ubiquitous language: is a unique language to enable developers, stakeholders and managers understand each other in prol to find the product actions. The Event Storming cards helps this understanding.
- Boundaries: is how we separate contexts. Note that when finished the workshop, we can see two different contexts, which show us what your boundary is.
- Context Map: we have all the context mapped and how they communicate with others.
Conclusions
Event Storming is an excellent tool to help us to get a better look at our product and what it does. Additionally, we can use this generated document to build our solution architecture, and how we can transform each context in a project/code. In my opinion, it increases our chance of creating something evolving, and easy to maintain.
Challanges / Next steps
- Think about an architecture to attend the Event Storming
- Segregate our domain to attend the contexts mapped
- Transform all journeys in code
Finally, for enterprises… think about how the squad can work together in this environment. The book “Team Topologies” may help us.
Acknowledgment
None of that would be possible without the incentive, help and teachings of Antonio Falcão.
