%20alt.svg){kind=small}
EventStorming has been revolutionary in the world of Domain-Driven Design. No technique has enabled domain experts and software engineering teams to collaborate so effectively at building and sharing a rich domain understanding.
EventStorming has been so successful that it has crossed the chasm and become a mainstream recommended practice. Since November 2018 it has been in the adopt phase of the Thoughtworks Technology Radar.
The benefits of EventStorming are numerous. From discovering new business opportunities to designing loosely-coupled microservice architectures, the power of domain experts and technical experts collaborating with a rich, shared model of the domain has been a game changer. The genie is out of the bottle.
With so many benefits, and such an apparently simple technique of scattering orange post-its all over your biggest walls, people often end up surprised and disappointed when their EventStorming sessions don’t result in hundreds of groundbreaking insights. They feel like their time was wasted and it is not something that suits them.
In my experience, the people who feel their time is wasted with EventStorming are those who don’t understand the benefits and how to achieve those benefits. They model only at a superficial level. This is why I always teach by first showing people the major goals they can achieve if they use the technique appropriately.
I teach EventStorming by working through a domain demonstrating the insights, opportunities, and problems a team modelling this domain could take away from a session. I focus on showing how to use modelling patterns and principles that lead to those insights.
Instead of going into an EventStorming session expecting mind-blowing takeaways for free, people know the type of benefits they will get and how they can get them. I find engagement, effort, and outcomes are all improved as a result.
In this article, I’m going to share my mini crash course with you. You can apply these principles to EventStorming or other modelling formats, even remote collaboration techniques.
If you remember these principles and apply them to your modelling sessions, you’ll go beyond superficial, disappointment-prone EventStorming and you’ll be almost certain to uncover deep insights into your domain that contribute tangible, maybe even profound, improvement to the systems you’re building and the way your team works.
All of the examples in this post are demonstrated using a Miro virtual whiteboard which you can access freely and anonymously.
Avoid Premature Abstraction
Modelling the domain with predominantly high-level events is the most common cause of “it feels like a waste of time” EventStorming sessions.
High-level events are abstractions of multiple lower level domain events, and down there is where the hidden complexity lies.
In the example above, these events are valid domain events, but they are so high level and probably obvious that we don’t learn anything from them.
Do not stop at this level of detail.
Don’t Model, Tell Stories
Even though we call it domain modelling, EventStorming is more about telling stories of the domain using domain events.
Rather than using high-level abstractions, we should talk in concrete scenarios. Tell the story from the perspective of each user persona, for example.
In this example, we model the domain from the perspective of an in-house recruiter and an agency recruiter. And immediately we uncover hidden complexity and events which occur only for certain types of user (the agency recruiter has an account manager but the in-house does not).
Apply this mindset to your whole domain and you’ll uncover many valuable insights.
The goal of EventStorming is not to create a model that covers all use-cases. The goal is to make discoveries.
Capture Hidden Intent & Complexity
When telling stories don’t just think about users, but of every concept in your domain like a job application, an order, or a journey. Think of the specific types of application, order, or journey.
In this example the recruiter has purchased an in-house plan. But again, we can zoom in and capture the real intention by showing if the user purchased a monthly or an annual plan.
Identify Where Upstream Affects Downstream
One of the benefits of capturing deeper intent and avoiding abstraction is that we can see how choices made in one part of the domain have an impact on the process downstream.
In this example, the type of plan the user chooses affects the level and type of support they receive when their job ad is not performing well.
When you identify branches like monthly or annual, you can look at every event in your domain and say “how does the choice of annual or monthly affect what can happen before or after this event?”. This kind of questioning will often bring you valuable discoveries.
Look For Missed Business Opportunities
When used well, EventStorming is an exceptional tool for identifying missed business opportunities.
One of my recommendations for finding missed opportunities is to look for where users drop out of the journey or where conversions are not successful.
In this example, the user is cancelling their plan. Effectively a customer is being lost. So we highlight the EventStorm using a bright pink post it rotated 45 degrees as a reminder.
In other scenarios we might identify ways to gain customers we’re currently missing, sell more services, or increase the user experience in some other way.
At some point during or after the session we can revisit the opportunities to explore possible solutions. You’ll be surprised at the quality of solutions you generate having a whole team of technical and domain experts together. It’s beautiful to watch.
Qualify Events With The Same Name
Whenever you see two events on the wall with exactly the same name, be suspicious. You probably have an abstraction.
In each case of the apparent duplicate event, ask yourself what can come before and what can happen after.
If different things can happen before or after the event at different times, qualify the name of each event.
In this example, the Job Ad Expired With No Applications event appears to happen twice. But it is only when this event happens the first time that the recruiter is offered 5 free days.
By keeping a single event with dual definitions, it leads to confusion in conversation. Different people use the same words but they are thinking of different events.
The solution in this example is to add precision to the event First Job Ad Expired With No Applications. This event only happens for the recruiter’s first job ad.
The second event is Job Ad Expired With No Applications After Free Extension which is self-explanatory.
Always Ask “What Can Happen Between?”
One of the great things about EventStorming is that the format allows us to find domain insights event if we know nothing about the domain.
At any point, we can ask “what happens between these two events?”. There is always hidden detail, and often it will lead to valuable insights.
In this example, we discover that advice is given to the recruiter in-between their free 5-day extension and the advert expiring.
Visualise Time Between Events
Asking “what can happen between these two events?” on your whole domain can take a lot of time and become inefficient. Something you can do to work out where to ask this question is to start by asking how much time occurs between events.
The larger the gap of time between 2 events, the more likely that there is hidden complexity that you should uncover.
In this example, there are 2 days between the free extension being accepted and the advice being offered. Why 2 days? What else is happening in that period of time?
Be Curious of Un-introduced Concepts
When you see a concept on your EventStorm that suddenly appears and plays an active role but hasn’t previously been introduced, be curious of missing domain insights.
Ask about the history of this concept. Where does it come from? What happens to it before this event where it suddenly appears?
In this example we saw previously, a recruiter is offered free expert advice if their adverts are not performing well.
But where does this free expert advice come from? By introducing this concept and tracing it’s own lifecycle we discover that it’s a phone call with an expert.
Now this backstory has been added to the EventStorm we can start to explore opportunities: what if we were able to automate the expert advice? Then we could offer it to all customers, and perhaps we could make it part of the job ad creation process rather than using it only in negative scenarios.
Be Sceptical of CRUD Naming
Created and Updated are extremely generic terms. They make sense in a database where data is created and updated, but these terms don’t convey why the data is created or updated.
When modelling domains, why things happen is key to uncovering domain insights. So instead of using created and updated, we should use domain terminology that expresses why something is being created or updated.
In this example, Job Ad Updated conveys very little useful information. Was there a typo in the job ad? Was a better description added? Or was the salary increased?
By expressing these different scenarios for updating a job ad, we get a better insight into domain behaviours. For example, if users are making a lot of typos, then we should spend time helping to prevent them. Or if users are often changing the salary, perhaps we should be helping them to specify a better salary during the creation process.
If Two Events Seem the Same, Show Both Anyway
Often people see two events that happen at the exact same time but have different names. They think it’s just two ways of looking at the same event, so it’s only necessary to show one of them. But this is a bad idea and it’s better to show both.
By showing both events, you might have uncovered the boundaries of sub-domains.
In this example, submitting a job application and receiving a job application seem to be the same thing just from the perspective of different users.
But submitting a job ad is the end of one journey and receiving the job ad is the start of another user’s journey. Maybe we can think of these are natural contours in the domain which are guiding us towards loosely-coupled modules in our software architecture.
Going Wide Before Going Deep
Before zooming in on a specific area of the domain and going into ultra-detail, go wide across the domain to avoid getting stuck in one part of the domain and not finding the major domain insights which can be found in other parts of the domain.
I see this so often. People argue about the intricacies of the user sign-up and login process because it’s at the start of the timeline, but this isn’t an interesting part of the domain where big discoveries can be found.
Go Deep Before Going Wide
As a counter-argument to the above advice, go deep into a specific part of the domain before going wide. If you stay at a high-level when going wide, people might not see the benefits and will lose enthusiasm.
If you can dig into a concrete story and uncover domain complexity, people will be keen to continue looking for discoveries in other parts of the domain.
As a facilitator, one of your big responsibilities is to help the group avoid going to deep in the wrong parts of the domain and while helping them to avoid staying to high level.
Use Empty Space to Visualise Unexplored Areas of the Domain
One of the best things I can advise for the broad vs deep conundrum is to use empty space on the wall as a way to visualise how much there is still to discover.
If you put all of the events close together or you focus on just a small part of the domain, attendees will not realise how much there is to discover.
But if you spread out high-level events with a lot of empty space between them, this communicates that there is a lot of unexplored space in the domain. This will help the group to avoid getting focused on one small area, when it is clear there is so much more to explore.
Conclusion
EventStorming is the most common and most effective collaborative domain modelling technique that exists today. It’s deceptively simple, and surprisingly easy to get wrong. The tips in this article help me to get the best from EventStorming and I’m confident they will help you too, especially if you share these tricks with attendees before your session starts.
Don’t forget that you can access all of the tricks mentioned in this article on the free Miro board.