After more than 7 years of intense Event Storming usage, in different contexts and countries, I often had to face the same problem: “This map of our context is great, can we now start coding” ?
I learn the hard way that trying to build software artifacts from the result of an Event Storming is an error, because you are just at a different level of processes and thinking.
Through the years I use different techniques in order to fill the gap between the post-its and the code. Since a couple of years, I use the combination of Event Modeling and Specifications by Example to bring the power of an Event Storming into the code, with an interesting success rate. I’ll try to describe how and why we do it in this article.
Disclaimer: a question of context
Despite the fact that I’m a huge fan of Event Storming, I acknowledge that it isn’t a silver bullet. It’s the most powerful tool I know to explore a known problem. From a Cynefin point of view, it’s a great tool in the complex or complicated area. But you can find a better tool in the Chaotic or obvious area. The good thing though is that, as a DDD consultant, I’m usually asked to work in complex or complicated projects.
Starting from an Event Storming
This is my (not so) secret weapon. If the context is complicated or complex (really often in my case), I start my consulting gig with an Event Storming (usually more than one to be fair). It allows me to step up in a few hours in domain understanding. I often receive praises from people after a few days because they are impressed by how quick and deep I can grab the business problems. It is nothing but Event Storming that allow me to understand in hours what the company needs years to discover. With experience in the exercise, you also notice some patterns in the way company organize themselves and their contexts, which allow you to get quick hints about what could harm the business (mostly bad communication and/or bad team dependencies).
Anyway, in the team I’m coaching, we always start with an event storming and agree on our bounded contexts before anything else. At this point, the whole team starts to be aligned on the problem and language, which is already awesome.
Then we want to code!
But now we would like to use this alignment in our code, and that’s where problems begin. First we usually have a legacy, and seeing how we build a big ball of mud instead of having clear bounded contexts can be quite depressing. Hence we agree on what the priority is, and we focus on one context. But you can’t ask your dev team “See this nice bounded context? Just do it now!”
Between sharing what a context could be and how it will be done with the code, we still have a long way to go.
Find your epics
Based on our event storming and the stories that were told to build it, we focus on one context and identify the epics inside. An epic is just a super set of features that makes sense together. Something like how the customer log into your system, or how a customer can manage its account for instance.
Use Event Modeling to model the epics
Using events, aggregates and commands from our Event Storming, we can build a blueprint of our story using an Event Modeling. At this step we often identify some missing artifacts (aggregates, events or commands), hence we’re always going back and forth to update Event Storming from Event Modeling and the other way around. It’s totally natural as we are just going deeper in the implementation, closer from the code. Hence we have to fix ambiguities and add more precise data.
Use commands to identify your User Story
We observe through experience that on a well-crafted Event Modeling, each command has the right size to be a User Story. For instance, if I have a ChangeAdress command, I can imagine this story:
As a user
I want to change my address
In order to receive my order at the right place
(you have to insist on getting the “in order to” because it is often missed).
Clarify your User Story with examples
At this point the ubiquitous language as spread through the team, the problem is shared by the whole team, and the only things that can go wrong is the evil in the details. As you discuss subtle use cases from the happy and unhappy path, I found nothing better than examples to share understanding. Hence the next step is to write a few examples for each user story. This part is full of back and forth between business analyst and developers, because they will refine and add examples as they go through the code. Again these examples might challenge the language, the Event Modeling, and then the Event Storming. It’s like a living thing, always evolving, always improving, as the team tackle the complexity of the domain.
A whirlpool model exploration implementation?
It is nothing but an implementation of the whirlpool process of model exploration as described by Evans itself.
I like to call this implementation ESEMUSE (for Event Storming, Event Modeling, User Story, Examples). The cool thing is that you can pronounce it easy muse, perfect for something that can give inspiration to the whole team 😉
I learn about DDD since 2012 (wow, that’s exactly ten years), and have heard about the whirlpool concept a few times, but never seen how it could be captured in practice. This is an example, but I’m sure that I missed lots of other good implementations of it ? What are your experiences about it?
Thanks for sharing.