EventStorming Modelling Tips to Facilitate Microservice Design
EventStorming is a hugely popular technique, allowing us to explore, analyse, and model business domains more effectively than traditional techniques. The result is that we create better designed software systems and teams of problem solvers rather than order takers.
Used judiciously, EventStorming gives us the ability to uncover enough information about our domain and our business that we can use it to design our microservices, bounded contexts, and even our teams.
Having run many EventStorming sessions in public training courses and privately for clients, we’ve noticed, however, that EventStorming can be applied sub-optimally leading people to question its value and leaving them feeling that they have wasted their time.
On the other hand, when EventStorming is applied effectively, we’ve seen plenty of successful sessions, many of which teams have used EventStorming as the basis for the design of their microservices.
In this article, we’ll share a few easy-to-learn techniques that will help you to get the most out of EventStorming so you can design more domain-aligned software systems.
If you want to see how to take the next steps and use your EventStorm to design microservices, check out our Bounded Context Canvas workshop recipe.
1. Avoid Premature Abstraction
One of the wrong turns that a group can take when beginning with EventStorming is to model their domain process at too high a level. They think “That was easy, what did we even learn here? Let’s not waste any more time with this EventStorming thing.”
In many EventStorming sessions, the killer domain insights are unlocked by modelling the domain at a deeper level. This is where you break illusions, test assumptions, and learn how your domain really works. This enables you to go beyond a naive software model to a truly domain-driven design.
Let’s take this example of an online jobs board:
A job poster signs up. They created a profile. They publish a job ad. A job seeker applies for the job. The job poster arranges an interview. The job seeker is offered the job.
This is how the domain works. But it is so superficial, so high-level, it teaches us nothing. We can model a few more flows like job application rejected making us feel like we have modelled our domain deeply, but it’s still so high level that anyone can work it out just by looking at the website
2. Start with Specific Scenarios
To avoid premature abstraction, start by modelling a single, granular flow. For example, a specific type of user purchasing a specific product at a specific time for a specific price.
After modelling a single flow, look for sub-branches within the flow, and then break out to adjacent flows.
In the job posting domain, we could start by modelling an external recruiter signing up to post a job. An external recruiter who purchases the large plan, and then an external recruiter who purchases the light plan.
We need to organise our job ads according to the business which we are recruiting for. And, the subscription policy has an opinion: if you’re recruiting multiple companies, you must commit to a different subscription model — and that affects how you get billed, and the type of reports you receive. Very different to other types of job poster.
As you model at a more granular level you’ll start seeing branches, fan-outs, fan-ins, and all manner of process patterns. For example, an external recruiter is subject to different subscription plans, needs special tools for organising their jobs, needs different types of report,
These are super-important clues about the parts of your domain which naturally belong and change together, and those which look the same but have a much looser relationship. This is type of information is key to architecting a domain-driven software system.
3. Capture Hidden Intent
We see many beginners make the mistake of adding Form Submitted events to their EventStorm. This is not a domain event it’s the technical implementation of a domain event. What matters is why the form is being submitted — what is the intent of the user?
Instead of using Form Submitted you could add a more domain-focused name such as Job Posted.
This is domain terminology, but it’s still insufficient. Here’s a technique you can use to gain deeper domain insights when modelling data submissions in your domain:
- List each individual piece of data (i.e. each field on the form)
- Enumerate the possible values for each piece of data
- Understand the significance of different values
- Model significant differences as separate flows
This is better demonstrated with an example: when a job posted, the form submissions contains the field: Employment Type. It can either be Permanent or Contract. The choice has high domain significance leading to variation in the business process which has an impact business outcomes.
In this case, therefore, maybe two events are better: Permanent Job Posted, Contract Job Posted. Then model each of these processes — look for differences in the process and look for similarities. You’ll get a ton of insights into the best way to design your system and especially for designing microservice boundaries.
4. Be Sceptical of CRUD Naming
Events with generic suffixes like Created, Updated, Changed, or Deleted are an indication that you are using technical terms to describe your domain rather than genuine domain terminology.
Updated is probably the biggest warning sign. Update is a very generic term that basically means changed. When we’re EventStorming, we’re trying to capture the richness of our domain, so we should be asking “why was something updated?”.
Not only will being sceptical of CRUD naming help you to develop a richer domain vocabulary which improves collaboration between technical practitioners and domain experts, but it will help you uncover additional flows within your domain. Understand each different reason for change and you will uncover many domain insights.
Instead of having a Price Changed event on your EventStorm you might have Price Discounted, End Of Season Sale Price Applied, Christmas Promotional Price Activated or something else specific to your domain.
5. Look for State Machines & Pivotal Events
State machines are everywhere in almost every domain. The concepts we are modelling go through different lifecycle phases, their states.
If you apply extra emphasis on looking for state machines, you’ll have more success at discovering boundaries in the domain which become boundaries of your microservices.
There is a special kind of event for identifying transitions between state machine states, known as Pivotal Events. Pivotal Events are a strong indicator of domain boundaries.
In the domain of IoT devices, we may have the following pivotal events: Device Manufactured, Device Provisioned, Device Installed, and Device Activated. While there are hundreds of events happen during the whole process, these are the key business events which signal a significant change, such as a device being moved from a warehouse and installed in a public location.
6. Ask “What if?” Everywhere
It’s quite easy to fall into the trap of only modelling the common or happy path scenarios in a domain. But there is so much to be learned by exploring all the edge cases as well.
To tease out the edge cases in your domain, look at each of your events on the wall and ask “What ?”. “What if there is a power outage?”, “What if the customer’s credit card is refused?”, “What if there is a fire in the warehouse?”.
Having a strong intrigue and curiosity for the domain will lead you to ask probing and challenging questions. This will lead you to many insights about the domain.
7. Switch to Single-threaded Mode if the Group is Struggling
Chaotic exploration is one of the hallmarks of EventStorming, where the whole group individually brainstorms ideas. Everybody is free to put all off their ideas, assumptions, and concerns on the wall.
Chaotic exploration is crucial for many of the discoveries EventStorming delivers. However, sometimes the energy is low, the group is confused, or progress is not being made for one of many possible reasons. What can you do about it?
While it is considered an anti-pattern for only one person to be putting the stickies on the wall while everybody else is watching, this approach, known as single-threaded EventStorming, can be surprisingly effective in helping a group to reach alignment and to build momentum.
There are a few variations of this pattern, but you can try this to get started:
- Pick one person to put the stickies on the wall
- Everybody else sits/gathers around them
- Pick one specific use case model
- Working forward, add one event at a time ensuring the group reach consensus before proceeding. If the group reaches an impasse, make a note and return later
- If there are any other doubts or concerns, make a note and return later — keep the progress moving
After a short single-threaded session, the group will have many ideas and additional scenarios they want to model in more detail. A good time to switch back to chaotic mode.
Mastering EventStorming & Microservice Design
Understanding your business domain is key to designing the optimal software system. Therefore, improving your ability to model business domains will enhance your capabilities as a system designer.
EventStorming is one of the best tools you can use for modelling business domains. The more you master EventStorming the more success you’ll have building software systems which satisfy the needs of the business.
Mastering EventStorming is not something you can learn in five minutes. But the sooner you start learning and the more you practice, the quicker you will get there. We hope the tips we’ve shared in this article will help to accelerate your path to mastery.
