Big Picture Event Storming
In the first article in the series about using the Domain-Driven approach for microservices design, we made a dive into DDD and focused on Strategic Patterns. Following Vaughn Vernon, the core of Strategic Patterns is, “Ubiquitous Language in an explicitly defined Bounded Context”.
UL, being spoken by all parties involved in the software development process, reveals the evolution of the business domain and reflects its changes in Bounded Contexts. Rewording, the UL is what defines Bounded Contexts, and the evolving language shapes the business domain model.
In my experience, in order to utilize DDD efficiently, it is better to start with domain discovery, knowledge sharing, and collecting the UL.
In order to discover the domain in-depth and precisely collect the Ubiquitous Language, we need to create a shared pool of business-knowledge. In practice, the knowledge about Business Domain has a very diverse nature and is spread through multiple experts with different backgrounds and positions: stakeholders, Product Owner(s), UX/UI designers, Engineers, Sales, Customer Care managers, etc.
Fortunately, in the world of DDD, there’s an underappreciated brainstorming technique called Event Storming, which helps to manage knowledge about the current state and future opportunities of the business domain. Event storming was created by a DDD practitioner and consultant Alberto Brandolini and is now widely used to reach the use of DDD.
Event storming is a brainstorming workshop where product delivery participants with different expertise share their part of business knowledge expressing it on colorful sticky notes on a wide wall.
What makes Event storming so efficient, is that it is a rapid, lightweight, intense, and highly interactive and collaborative workshop. It’s a synthesis of facilitated group learning practices from Gamestorming and the principles of Domain-Driven design (DDD). The event storming isn’t limited to software development and could be used to tackle any business domain.
There’re different types of event storming workshops. A Big Picture event is usually used to discover business domain and share knowledge and usually ran in total isolation from software design activities. The participants should mainly consist of businesspeople: stakeholders, product owners, customer care, sales, etc.
A Sofware Design event storming is more focused on system design and involves developers, product owners, UX/UI designers, and engineering managers.
How to Event Storm?
In this article, we focus on a Big Picture.
First of all, decide on the boundaries of the business domain you’re gonna discover. On a Big picture event storming, you may tackle the whole business, or narrow down your focus to specific subdomains. Understanding the scale will help you to define the invitee list.
The gems of any brainstorming are people and their knowledge. So, for a successful event storming, inviting the right people with appropriate knowledge is essential as well. The ideal number of participants could depend on the nature of your business, but I found 8–10 to be the optimal number. Try to diversify the participants by their knowledge areas and expertise, so the group together owns the business knowledge about the part of the business you are going to discover.
Preparation
Now, prepare the necessary supply. If you’re going to do an offline event storming, you need a room with an 8–10 meters-long wall, the bigger the better. You’ll also need a paper roll of the same length and 70–100 cm height and a bunch of sticky notes. A cheap white plotter paper roll works perfectly. The roll is folded to the wall and the notes will be stuck there.
For online event storming, I found the Miro to be a very convenient tool for it. The pic above is taken from a workshop I ran during the Coronavirus lockdown, which proves it’s convenient for online brainstorming. All the following examples in the article are done using the same tool.
As mentioned above, the knowledge is expressed on colorful sticky notes, so you’ll need them as well. Below is a picture from where you can get the color, size, and purpose of each. I’ll explain each type of artifact in detail later in the article.
And not least, prepare markers for each of the participants to write down on the sticky notes.
Time
The length of an event storming depends on the size of the subdomain you’re going to storm. It’s very useful to run a day-long big-picture session for the first time in order to understand the scope of your domain, its’ complexity, and the most challenging parts. Just make sure, to have necessary breaks and some food and drinks to keep the participants fresh.
For the future stormings, where you may focus on specific subdomains and discover particular problems, 2-3 hours-long sessions with a short break in the middle could be optimal.
Let’s start
The scenario of the technique is to assess the current state of business first, and then to discover the most effective areas for improvements. So keep focus on the current state of the business domain.
To understand event storming let’s get familiar with the key artifacts.
Domain Event
Any event storming starts with collecting the knowledge about your business, expressed in a form of Domain Events, which are stuck to the wall in time order from left to right.
A Domain Event is any event that is important for your business and makes an explicit impact on it. The event could happen inside or outside your business system. By convention, each event is expressed in a past term verb, written down on an orange sticky note.
To lower the entry threshold for participants, the facilitator usually makes the first step by sticking pivotal events, which emphasize the major happenings in the business from end-to-end.
Following the example of a hailing application from the first article, the pivotal events could be: Booking is requested, Booking is accepted, Ride is started, Ride is finished. Bellow is how the pivotal events could be distributed on a 10 meters-long wall.
Now the participants can start fulfilling the gaps between and around the pivotals.
It is the most important part of the whole storming, where the common goal is to share maximum domain knowledge from each of the participants.
Try to keep chaos, and facilitate knowledge holders to only write down the events and stick them to the wall straight away without validation from the others. Even if the events are expressed in long sentences and not in the past term, or duplicate each other, don’t interrupt the knowledge sharing flow, and let people brainstorm.
If you see discussion circles, then jump in and support by answering questions and solving struggles. Keep the process interactive by supporting the highest possible level of involvement of everyone for at least 20–30 mins.
Remember, that the events should be ordered in time from left to right. Reminding people to keep the order, at least partially, during the first phase, will help to build a more consistent event flow.
In about 30 minutes, depending on the size of your domain, the activity will slow down and people start just looking to the wall or run discussions without any outcome onto the wall. That is a sign to wrap up the first phase and go to the next one — a walkthrough.
Walkthrough or Storytelling
At this moment, the majority of domain knowledge is already on the wall. And your main goal is to clean up, order and structure it by walking through the wall from left to right and audibly reading the story written on the sticky notes, clarifying and asking questions to the authors — knowledge holders.
If the knowledge holders experience an event storming the first time, then the sticky notes are very likely to look like on the picture below. It represents just the part of the wall, and the pivotal events from the previous picture are circled here on Pic.3. All are enumerated only in order to easier reference them in the article.
As you see, most of the formulations are not following the policy of the ideal domain event, to be a short statement in a past term verb. Also, some of them are duplicative by meaning and/or ordered incorrectly, and even grammatically incorrect. Let’s walk through the wall and fix it.
The 1 and 2 are duplicative, and the 2 has more sense within the domain. Also, the 2 is not fully correct, because not the Driver, but rather a Car is looked up for. It could be rewritten as “Cars are looked up” or “Cars are looked up by Passenger” or “Passenger looked up for Cars”. Mentioning the Passenger here is important, but not mandatory. So, let’s delete the 1 and replace the 2 with “Cars are looked up”.
The 3 and 4 are duplicative as well. Also, 3 is not correct. Passenger doesn’t request a particular driver, but rather just requests a Booking. So, let’s delete the 3 and leave 4.
After the cleanup entry, let’s ask the knowledge holders to zoom in to the two following sticky notes and validate the flow.
If anything is missed or should be changed here? Well, no need to be an expert, to see missing events. And the Product Owner could correct you, that one event prior to the car lookup is “Pick Up Point address is entered”. And one after is “Car class is selected”.
Another question, which could arise, is why we make a Booking, not a Car request, while Cars are looked up. It is a common case of ambiguity of entities in any business domain. And event storming sessions always benefit from such kind of discussions. In this particular case, someone, e.g. UX/UI designer, could have a strong opinion that from the Passenger’s perspective it is a Car to be requested. But, some of the stakeholders could object that the physical Car is complemented with a Driver, Customer Care support, Payment gateway, and many other details, that are packed into a service unit, which they get used to calling a Booking.
So, the settled terms of Car and Booking are important additions to the Ubiquitous Language, which I highly recommend to update after each event storming. The candidates for UL in this article are highlighted by bold italic, and we will add them to Ubiquitous Language later in the article.
For now, let’s clarify the meaning of Booking with a Definition artifact, that is written down on a big white sticky note. You can see it on the Pic. 4 below. We’ll talk about Definitions in detail soon, but now let’s continue with the event flow.
Let’s continue audibly reading the story, written on the other sticky notes on the Pic. 3: “After Booking is requested, Passenger may cancel it”… sounds valid. Note #5 could be reworded to “Booking is canceled” event, which is performed by Passenger.
Let’s read the story again: “After Booking is requested, Passenger may cancel it”… sounds better.
As you can see, the Booking is Accepted and Booking is Canceled are placed in parallel to reflect two possible event flows.
And again, what about the order?
What happens after the Booking is canceled?
If the cancelation is possible only after Booking is requested?
If no one raises a point, then maybe we could clarify it with an expert.
- Sure! Passengers may cancel a Booking at any moment before a Driver arrives at Pick Up Point. In our current scope it means both before and after a Booking is accepted by a Driver.
- Pick Up Point? Sounds like a starting point of a Passenger’s journey. When it is selected? And have you just mentioned a Driver is Arrived event?
- Yes, we forgot to add the Pick Up Point is Selected event after the Car Class is Selected. Driver is Arrived is happening after the Booking is Accepted and before another business-critical event, Ride is Started.
Finally, if a Booking is canceled, then Passenger is returned to the very beginning of the booking flow.
Let’s reflect that business knowledge in the event flow.
And we continue to walk through the wall and read the business story:
- After Booking is requested, it could be either accepted or canceled…
- “Wait!” — said the Sales Manager — “According to the definition, Booking is a system of services, requested by a Passenger, including Car, driver, CC support, etc. So, Driver doesn’t accept Bookings, but Offers — it is what we call it.”
- Could you please write down the definition of Offer on a big white sticky note and stick it to the wall? Also, please clarify when and how Offer appears.
- Creation of any Booking triggers creation of a new Offer.
Solving the intersection of sub-domains
From the first article about DDD, Strategic Domain-Driven Design, we know that “If a team starts using a new term to express an existing concept or an existing term is used to express a new meaning, then it is a red flag for the team that the subdomain’s boundaries are overlapping.”
Initially, in the hailing business domain, Booking was used as a universal term to mean a service unit in both Passenger and Driver subdomains. With the evolution of the domain, the term started to have more specific meanings for each of the Passenger and Driver subdomains, and thus was split into Booking and Offer.
An even more explicit example of how a concept is split by contextual meanings is the last Booking is Canceled event. There are two actors, who could trigger the event, Passenger and Driver. Obviously, a single unit of a hailing service has very different meanings for them.
Roughly:
- Using a booking interface, a Passenger orders a taxi to move from point A to point B, and pays for it some amount, consisting of the Driver’s revenue, Company’s margin, and additional tips. For passengers, it happens mostly from time to time, of necessity to move from A to B.
- Using another interface, a Driver selects an offer from the list. The offer has only the revenue, pickup and dropoff points, and contact info about the passenger. For Driver it is a job, so he does it regularly.
Thus, the last Booking is Canceled could be triggered only by Passenger, while Driver may trigger Offer is Canceled. A Driver doesn’t interact directly with Bookings, but via Offers only.
Let’s reflect this contextual splitting of the Booking and Offer on the wall.
Event storming is very useful to identify and document such contextual distinctions. Sometimes, experts in different domains discover the evolution of a concept during the session itself. While explaining the meaning of a concept, experts provide distinct definitions and surprisingly find out that they’re already giving the same concept different context-specific meanings. It happens due to growing silos between people working in different sub-domains, and event storming is a very powerful tool to foster alignment and knowledge-sharing.
To keep the storming consistent, add definitions one by one as they appear. Now, Let’s stick them to the wall and continue the walkthrough after…
Definitions
As mentioned above, big white Definitions sticky notes are used to highlight business terms. While orange Events are first-class citizens in event storming, Definitions constitute the Ubiquitous Language.
During an event storming session, whenever you see or hear a business-specific term, acronym, or even informal slang, ask someone who mentioned it to write it down and stick to the wall above the events. By asking others to do that, you’ll facilitate a deeper involvement in the storming process, and often raise new questions and discussions within the group of participants.
Make sure that the definitions are explicit, context-specific, and include conditions, roles, and dependencies if any.
After the session, always add new definitions to the Ubiquitous Language. Personally, I’m using Confluence pages to collect the UL for each subdomain. After copying the terms from the storming wall to the Confluence page, share the updates with appropriate users, ask to validate, and necessarily remind others to use the UL in conversations, other workshops, UX/UI mockups, code, and everywhere in the context of the business.
Below are the definitions we’ve met so far.
… Continuing the walkthrough
- After Offer is accepted, the ride starts… Something important is definitely missed here.
- The “Driver is Arrived”, for sure. Or, if he didn’t arrive, then we call it No Show
It’s common for people, who hadn’t had prior experience with event storming, to focus mostly on the core subdomains, like Booking and Offer in the hailing service. In this case, direct knowledge holders to the supporting subdomains, for example, Notifications and Payments, and discover events happening there.
After Offer is accepted and/or Offer is canceled, we could add a Passenger is notified event. And after Booking is canceled we may add Driver is notified event, but only in the case of an appropriate Offer is being already accepted by Driver. Such conditions, are documented with a Policy artifact, which we’ll talk about a bit later.
Below are some examples of events happening in supporting subdomains.
I’ll not include it to the whole picture in order not to overload the narrative. But at the end of the article, an example of a real event storming result will be provided.
Commands
After you feel that most of the domain knowledge is reflected in events on the wall, focus on the Commands that trigger appropriate Events. Write down Commands, important for the business, on a light blue note and place left to the Event they spawn.
A Command is a message that represents the intention of a user, and could be expressed as an action, like Request Booking, Cancel Booking, Request refund, etc.
Let’s add them to our wall.
Besides users, Commands might also be triggered by time, documents, or external events.
The most frequent Command triggers are users, and in Event Storming, they are modeled with Actors pattern.
Actors
The Actor artifact in event storming is mimicked by a small yellow sticky note and reflects a user, who triggers a particular command. The size of the sticky note is smaller than the other quadrants, e.g. orange events or blue commands.
We don’t need to overload the whole picture with pinning an Actor to every event, but just enough to eliminate ambiguities. E.g., the last Cancel Offer could be triggered by Driver, and the Cancel Booking by Passenger.
Policy
Policy artifact is used to document conditions and policies for events to happen. So, on a storming wall a policy stays between a Domain Event and a Command. Policies are formalized like “Whenever…X, then…Y” or “If…X, then…Y”.
In our case, it could sound simply as “Whenever Booking is created, then create Offer”.
We use a big lilac post-it for policies.
Let’s put to the wall the definition of Offer, policy, and appropriate “Offer is created” event.
You may notice that before we named the event Booking is requested instead of Booking is created. Events collected during event storming should reflect the most significant happenings in the business. And since we have split to Booking and Offer, then Booking is created event sounds more business-oriented. And at the same time, it is general enough to highlight the big picture. If we’d have an event storming for an in-depth discovery of just the Booking subdomain, then a chain of events could look like Booking is requested, Booking is validated, Booking is created, etc. Such sessions focused on a specific subdomain, make sense to run after a big-picture storming, which we’re exploring an example of.
Often, especially when a workshop format is new for the participants, they could know, but unintentionally not share valuable knowledge. Anticipating knowledge existence and facilitating sharing is a skill. Try to gain it by focusing on the domain and asking questions.
- If cancellation of a Booking is appropriately reflected in the Offer?
- Yes, then the Offer is cancelled as well
- Could you please document the policy on a big green sticky note: “Whenever a Booking is canceled and the Ride is not started yet, then cancel the appropriate Offer”.
And what happens if a Driver cancels Offer?- Then the Booking is canceled.
Those two policies were easy. But what if we have complex business conditions?
According to our domain experts, the last Booking is canceled event could, unlike the other cancellations, cause a penalty for the Passenger. E.g. depending on the time passed after the Offer is Accepted event. A Driver may also be penalized when he cancels an offer.
In event storming, such conditions are expressed by a Policy artifact on a big green or salad sticky note.
Let’s ask our knowledge experts from each of the Passenger and Driver subdomains to explain the penalty policies in detail. Here they are below.
- For the Passenger: if the booking cancellation is done in more than a half time to the Pick Up Time, then charge the Passenger with 10% of the Booking price.
And, if it is the 3rd cancellation during the last 24 hours, then the penalty is 50%. - For the Driver: if the offer cancellation is done in more than a half time to the Pick Up Time, then penalize the Driver for 20% of the Offer price.
With help from the invitees, let’s stick the Booking cancelation policies and new definitions to the wall. The Offer cancelation policies should also be added, but I omit it to keep the picture lighter to read.
When the event flow is branching like after the Offer is Created, it’s helpful to use arrows to keep flows visually split and eliminate a mess. In the case of the next branching, e.g. into Ride is Started and Offer is Canceled, the arrows are redundant.
It is very important to understand and clarify to others, that branched flows are independent and only one of them lives in a moment.
So, even though the Booking is Canceled is placed later than the Ride is Started on time ax, it doesn’t mean that they are happening one after another. Those are two independent flows, and only one of them is active after the Offer is Accepted event.
Comments
Sometimes you may need to add a description in a free form to something in the domain. That is what the Comments artifact is used for. Comments are written on a small white sticky note and stuck to another artifact or just on a certain place on the wall.
If you have events that could happen in arbitrary order, then don’t put them one after another, but in the same flow, and add appropriate comments. Imagine, a Customer may choose a payment method right before starting a booking funnel or exactly before the Booking is Requested event.
Earlier, one of our knowledge-holders mentioned that a Booking could be canceled any time between Booking is Created and Ride is Started events. To make this knowledge explicit, it’s worth using the Comments.
Improvements & Opportunities
One of the important advantages of the event storming’s interactive format is that it helps to identify inconsistencies, points for improvements, and find new opportunities for business domain development. Such moments could be raised by discussions with controversial opinions or when someone shares a lot of knowledge that is new to others. In order to document it, a small purple or magenta sticky note is used as an Improvements & Opportunities artifact.
For example, in early-stage startups, such improvements may relate to automation if flat files, e.g. *.word or *.xlsx, are used to store, process, or share data. Or an improvement could be to introduce a conversational AI into the Customer Care subdomain to reduce waiting time.
An opportunity could be to advertise and sell satellite goods and services to a customer. For example, most hotel booking services, after customers have already paid for the main service already, offer to book a car or an excursion. Ticketing services are using a similar business model.
Let’s dive back into our interactive workshop and listen to a dialog between a Software Engineer and SMM specialist:
- As a father and a hailing service user, during the booking funnel I’m missing option to choose from the Drivers who have a baby seat.
- We had it in the past, but then removed because any additional step between opening the application and clicking the “Confirm” button reduces conversion rate. But now we’re working to provide this option to the Bookings, which Drop Off Locations are kindergartens and schools.
- Nice! Let’s add it to the wall
Someone may object, that the opportunity sounds much like a policy + event. But it’s often important to remember, that event storming should reflect the current state of your business domain. If you want to discover future development more in-depth, then run an event storming focusing on and documenting more with Improvements & Opportunities artifact.
Systems
The last valuable subject we are going to discover in the big picture event storming is Systems.
A System could be anything that provides solutions in your business domain, e.g. a deployable service developed inside your company or external third-party providers that your company is integrated with. An example of an external system could be an email-service or push-notifications service which sends notifications to Passengers, checkout service, Excel sheet, Google file hosting, Facebook business page, or a smartphone which Passenger and Driver may use to call each other.
Systems are documented with a big pink post-it.
Below are two parts, which I extracted in order not to overload the picture, where you can see examples of Systems: Booking funnel, Booking system, Offer system
Also, we may notice cases of commands being triggered by a system, but not by a persona: Generate Offer and Notify Passenger.
Ubiquitous Language
A very important outcome of the workshop is UL. After each event storming it’s absolutely necessary to collect all the collected definitions to a dedicated place and agree on using them among the colleagues and also to reflect the UL in the programming code. More about the role of UL you can find in the previous article Strategic DDD.
Summary
We have done the first part of business domain discovery with Big Picture Event Storming.
It gives us a picture of our business and reveals:
- data flow represented by events,
- highlights points for improvements and opportunities
- represents the integration of internal and external systems
- helps to fulfill UL
To give you a broader picture, below is a partial result of our storming. To think big, imagine the flow continued till the Ride is finished and rated. Then think about the hailing app having not just taxi, but also scooters, bikes and other transportation options. And now expand the business domain into the B2C and B2B contexts.
The next step to design microservices using DDD is to run Software Design Event Storming and shape future microservices using Bounded Contexts and DDD tactical patterns.