#49 DDD Series: Organize High-Level Workshops
Before diving into code, you need to understand what you are actually building. Event Storming workshops bridge the gap between business ideas and technical implementation - here is how to run them.
Now that you have learned the fundamentals of your business, it is time to bring the vision to life by hosting the first interactive workshop.
Plan your first workshop with decision-makers and domain experts - including developers (especially the ones who work on legacy systems as they often understand business processes deeply).
Keep your workshop intimate with no more than 10 people (my rule of thumb). Working with a large system? Start with understanding your most vital workflow first. A medical practice might focus on scheduling, while an insurance company could tackle claims processing, and retailers might prioritize their ordering system.
Next, structure the workshop into shorter segments to maintain productivity. A typical 3.5-hour session includes:
Three 1-hour blocks with 5-minute breaks
15-minute buffer at the end
Alternatively, you can plan six 30-minute segments with 5-minute breaks.
When modeling business processes, you will usually work with one of below states:
As-is state (focusing and modeling the current process)
To-be state (focusing and modeling the desired future state)
In my case, the modeling is usually done with either Event Storming or Domain Storytelling, or with a combination of both. There are also other techniques, so feel free to use the one that is comfortable for you, and what is most important - for participants.
In this post, I will show you how to leverage the power of Event Storming Big Picture workshops to start analyzing our fitness domain.
Think of Event Storming as your process detective kit. It helps uncover how things really work by focusing on completed actions – those 'done deals' in your business like Contract Signed or Offer Published. The magic happens in three layers.
It all starts with the Big Picture – a high-level map of events that shows what happens when highlighting any trouble spots. Next, you move to Process Level workshops where you focus on the details of the process - you will add actors, commands, policies, and read models. Finally, at the Design Level, you will explore modeled processes, focus on design, find aggregates, and refine business rules. At this level, pseudo-code may accompany sticky notes.
To handle such a workshop you will need plenty of wall space, sticky notes in different colors (static ones work best), and markers. Keep everyone on their feet during in-person sessions – it keeps minds sharp and ideas flowing. Running it remotely? Tools like Miro create that same collaborative feel.
For the Big Picture session, I usually use four types of notes:
Event. It is usually pictured with an orange note. It represents every business event in our domain. It does not represent a technical event, so Button clicked is not something you should care about. The rule of thumb is to name it in the past tense (something happened) because it is an event that has already occurred and cannot be changed.
Hot Spot. It is usually pictured with a red note. It represents every question or input that is unclear or cannot be answered during the workshop. This ensures that these concerns are not forgotten and can be addressed in future workshops.
Comment. It is usually pictured with a yellow note. It represents additional information, clarifications, or observations that participants want to add to the conversation. They ensure that important information is not overlooked.
External System. It is usually pictured with a pink note. It represents an external system that interfaces with the domain. External systems are not directly controlled by the modeled system but play a significant role in its operation. They may send or receive messages, data, or events to and from the system, influencing its behavior or being influenced by it.
Begin the workshop with practical preparation: equip everyone with plenty of colored notes and markers. Before diving into your business process, spend 30 minutes mapping something familiar, like a bike rental. It will help everyone grasp the techniques's basics.
With the team prepared, share your workshop's goal. In fitness, for example, you might aim to create a comprehensive view of membership enrollment and access management. Start the modeling by posting an orange event note centrally on your workspace. This first event – perhaps Contract Signed – becomes your temporal anchor, with the full process timeline growing organically in both directions: from offer selection through to pass registration and membership renewals.
Try to establish a 'no wrong answers' atmosphere where everyone feels confident contributing their process knowledge. When you spot similar events on the wall, pause for a quick alignment check – sometimes apparent duplicates are actually distinct events that share a name but serve different business functions.
Keep the momentum going with targeted questions: “What triggers this event?” or “What are the failure scenarios here?” When discussions hit an impasse, document it as a hot spot and move forward. That first hour should feel almost chaotic, with ideas flowing and sticky notes multiplying across the wall. If you are not seeing this energy, you either need to bring in different perspectives or provide more concrete examples to jumpstart thinking.
After the first part, the wall should look similar to this:
As you can see, there are both:
Events that are related to business, e.g. Contract signed or Pass expired
Events that are technical, e.g. Request sent to API or Button clicked
The first thing you want to do is to get rid of the technical events, as they are of no interest:
Time to arrange your event landscape chronologically. You can work forward – starting with the trigger event and following the natural flow of time, which matches how we typically think about processes. It helps capture fine details and reduces the risk of missing steps.
Alternatively, work backward from the final outcome. It often reveals unexpected connections and alternative paths you might miss going forward but it is easier to overlook intermediate steps.
After grouping, you should see an image similar to this one:
Now that you have your event timeline, it is time to identify the pivotal events that shape your process. Look for events that mark major transitions – where actions become hard to undo, like finalizing a payment, or where responsibility shifts between actors. These pivotal events often trigger new subprocesses or create natural process boundaries.
Each process will have several pivotal events, and they will help transform your linear 'snake' into something more meaningful:
It is worth mentioning that elements within each of the above groups should be closely related and focused on a specific purpose or business capability (high cohesion).
During the grouping, you might observe that there are unclear points, or participants want to add additional context to discussions. Mark them with hot spots (unclear points) or with comments (additional context):
Your final task is transforming those event groupings into named process segments. Hand this responsibility to your participants – they know their business domains best.
That is it. We are done with the high-level workshop. The result will be used during an in-depth Process Level workshop.