Event Storming is one of the most effective techniques we have for domain discovery. But framing it only as domain discovery misses part of the picture. It also helps build shared understanding, expose differences in language and mental models, identify potential bounded contexts, and reveal boundaries around responsibility.
What makes Event Storming powerful is not its notation. It is the conversation that the notation enables.
Unfortunately, Event Storming is also remarkably easy to imitate.
Its visible mechanics are simple. Put people in a room, cover a wall with sticky notes, write domain events in the past tense, arrange them on a timeline, add commands, actors, policies, hotspots, and perhaps some boundaries. At the end of the session, the board looks impressive. People take pictures and leave.
It certainly looks like Event Storming.
But the question is simple: What did we discover in this session?
A successful Event Storming session should change our understanding of the domain. It should expose assumptions we did not realize we were making, reveal disagreements hidden behind familiar terminology, surface business rules and exceptions, and force us to question things that previously seemed obvious.
If Event Storming only confirms what everyone already believed, it was probably documentation, not discovery.
This distinction becomes especially important in Big Picture Event Storming. At that level, the primary goal is not to design software or produce a clean model. It is to explore the business landscape and develop a richer shared understanding of how the domain actually works.
So the real challenge is not knowing how to run an Event Storming workshop, but recognizing when it has stopped producing discovery. The following signs are the patterns I would watch for most closely—especially in Big Picture sessions, where the goal is to uncover how the domain actually works before we start designing around it.
1. We Invite the Right Roles, but Not the Right Knowledge
A workshop may appear perfectly cross-functional on paper. There is a product manager, a software architect, several engineers, a business analyst, and perhaps someone representing operations.
That does not necessarily mean the right knowledge is in the room.
Domain knowledge does not always follow organizational titles. The person who understands a process best may be the operations specialist who has handled its exceptions for five years. It may be the support representative who knows why customers repeatedly encounter a particular problem. It may be someone in finance who understands why a transaction that appears completed in the system is not actually considered complete by the business.
These people often carry knowledge that has never made its way into requirements, diagrams, tickets, or documentation.
This becomes especially important when discussing exceptions. Official processes tend to describe how things are supposed to work. Domain experts often know how things actually work when reality gets complicated.
If the people in the room can explain the normal flow but repeatedly need to say, “We should ask someone from operations about that,” or “I think finance handles that part,” we have probably invited the right organizational roles but not the right domain knowledge.
And without that knowledge, a dangerously clean model can emerge.
2. We Enter the Room With the Answer Already in Mind
Event Storming should be capable of proving our assumptions wrong.
If it cannot, it is probably not discovery.
Yet workshops are frequently organized after important decisions have already been made. Perhaps the engineering organization has decided to split a monolith. An architect already has a candidate service boundary in mind. A new platform is being designed. Teams have already been reorganized around certain capabilities.
Then Event Storming is introduced to “discover the domain.”
The danger is subtle. Instead of exploring what the business tells us, we unconsciously search for evidence that supports the model we already prefer.
Events start getting grouped around proposed services. Boundaries appear suspiciously close to existing team structures. Ambiguous concepts are interpreted in ways that support the architecture we already have in mind.
At that point, Event Storming has become a validation exercise.
There is nothing wrong with entering the workshop with an idea. The problem is when we start looking for evidence to support it instead of evidence that might challenge it.
True discovery requires the possibility of surprise.
We should be willing to leave the room with a different model from the one we expected to find.
3. Domain Experts Become Guests in Their Own Domain
This is one of the clearest warning signs.
The session starts collaboratively, but after a while the engineers take control of the wall. They understand the notation. They know what commands, policies, aggregates, and bounded contexts are. They are comfortable reorganizing sticky notes and discussing abstractions.
The domain experts gradually move backward.
They stop modeling and start answering questions.
Eventually, engineers are standing in front of the board discussing how the domain works while the people who actually live inside that domain are sitting behind them watching.
Something has gone wrong.
The purpose of Event Storming is not to let software professionals extract information from business people and turn it into a model. It is to create a shared modeling environment where different perspectives collide.
Some of the most valuable sentences in an Event Storming workshop sound like this:
“Yes, but only if…”
“That is not actually when we consider it complete.”
“We use the same word, but those are two different things.”
“Normally yes, except for international orders.”
“The system says that, but operationally we do something different.”
These are not interruptions to the workshop. They are the workshop.
If domain experts are mostly confirming a model created by engineers, we are very likely modeling our assumptions about the business rather than discovering the business itself.
4. Premature Solutioning: We Solve Before We Understand
One of the clearest signs that discovery is breaking down is when the conversation starts moving toward solutions before we have developed a sufficient understanding of the problem.
Sometimes this happens at the implementation level.
A domain expert explains that something happens after an order is accepted, and within minutes someone asks whether the interaction should be synchronous or asynchronous. Another person mentions Kafka. Someone else wants to know which service should own the database or what the API should look like.
Sometimes premature solutioning happens at a more conceptual level. A cluster of events starts looking interesting and someone immediately identifies an aggregate. Another person proposes a bounded context. Soon the conversation is about service boundaries, consistency models, ownership, or team structure.
The vocabulary is different, but the underlying mistake is the same:
We are trying to design the solution before we fully understand the problem.
The questions we ask begin to change.
Instead of asking:
“Why does this happen?”
we ask:
“Which service should handle it?”
Instead of:
“Who makes this decision?”
we ask:
“Where should this logic live?”
Instead of:
“What does ‘completed’ actually mean to the business?”
we ask:
“Which event should represent completion?”
Those may eventually become exactly the right questions. The problem is timing.
Especially in Big Picture Event Storming, our first responsibility is to understand the landscape. We are trying to discover behavior, language, rules, decisions, dependencies, conflicts, and exceptions. When we move into solution mode too early, the design space begins shaping the discovery process rather than the other way around.
This becomes even more confusing when participants are working at different levels of abstraction without realizing it. One person is trying to understand the business process. Another is looking for bounded contexts. A third is thinking about aggregates. A fourth is already imagining microservices.
Everyone may be making reasonable observations, but they are no longer answering the same question.
Big Picture Event Storming, Process-Level Event Storming, and Design-Level Event Storming exist at different levels for a reason. Moving between those levels is perfectly legitimate, but it should be intentional.
Before asking how the software should model the behavior, we should first understand what the behavior actually is and why it exists.
There will be a time for architecture.
There will be a time for aggregates.
There will even be a time for Kafka.
But discovery should earn those conversations first.
5. Existing-System Bias: We Model the Software Instead of the Business
Ask what happens after a customer confirms an order and listen carefully to the answer.
If it begins with:
“The Order Service publishes an event to the Fulfillment Service…”
we may already be seeing existing-system bias.
Existing software has enormous gravitational pull. Service names, database tables, APIs, queues, workflows, and architectural boundaries are familiar and concrete. We interact with them every day, so over time they begin to shape the way we describe the business itself.
Eventually, we stop seeing them as implementation decisions.
They begin to look like reality.
This is particularly dangerous in legacy systems. A boundary may exist because of a technical limitation that disappeared eight years ago. Two concepts may live in the same service simply because one team happened to own them when the system was created. A workflow may look like a fundamental business process when it is actually a workaround for an old integration.
Over time, these historical accidents become institutional knowledge.
Then we reproduce them during Event Storming.
The resulting model feels correct because it resembles software everybody already understands. We recognize the services. We recognize the flows. We recognize the terminology.
But instead of discovering the domain, we may simply be reverse-engineering our current architecture with sticky notes.
There is an important difference between:
“The Order Service sends the payment information to the Payment Service.”
and:
“The business needs to know whether payment has been authorized before the order can proceed.”
The first statement describes one implementation.
The second describes something about the domain.
This distinction matters because our current software is only one interpretation of the business. It may be a good interpretation. It may also contain years of compromises, obsolete assumptions, workarounds, and accidental complexity.
A useful question to ask repeatedly during a workshop is:
“Would this concept still exist if our current software did not?”
If the answer is no, we may be discussing implementation rather than domain.
Our architecture can help us understand the domain, but it should not define what the domain is allowed to be.
The software is a model of reality.
It is not reality.
6. We Rush to Resolve Disagreement
Two domain experts disagree.
One says an order is completed when the package is delivered. Another says it is completed only after the return period expires.
The room becomes uncomfortable.
Someone wants to keep the workshop moving, so a definition is chosen. A sticky note is updated. Everyone accepts and continues.
It feels like progress.
But we may have just removed one of the most valuable discoveries of the entire session.
Disagreement is information.
When different people use the same term differently, it may indicate different business concepts hiding behind the same word. When two departments disagree about when something happens, they may be operating under different models. When a rule that one expert considers universal immediately produces an exception from another expert, we have learned something about the domain.
These conflicts are not noise to be eliminated.
They are signals to investigate.
This does not mean every disagreement needs to be resolved during the workshop. Sometimes the right outcome is simply to make the disagreement visible.
Put a hotspot on it.
Write the question down.
Identify who needs to investigate it.
A question mark on the wall can represent more learning than twenty perfectly ordered events.
Artificial consensus is not shared understanding.
7. We Explore the Happy Path and Call It Done
Almost every domain looks simple when described through its happy path.
A customer places an order. Payment is authorized. The order is prepared. The package is shipped. It is delivered.
That sounds straightforward.
Now start asking uncomfortable questions.
What if payment succeeds but stock reservation fails?
What if only part of the order can be fulfilled?
What if the customer cancels while the warehouse is already preparing the package?
What if the package is delivered but the customer claims it never arrived?
What if Finance and Fulfillment disagree about whether the order is complete?
Suddenly, the domain looks very different.
Happy paths reveal workflows.
Exceptions reveal business rules.
And business rules are often where the most valuable domain knowledge lives.
Unfortunately, workshops frequently spend most of their energy making the main timeline coherent. Exceptions appear as annoying branches that threaten to make the board messy, so they are postponed for later.
But the messy parts are often exactly where we should spend our time.
This does not mean a Big Picture session needs to model every edge case in detail. It means exceptions should be treated as signals. If an apparently simple event repeatedly produces “except when…” discussions, there is probably something worth exploring there.
A domain that contains no exceptions is often a domain we have not explored deeply enough.
The Board Is Not the Measure of Success
There is something psychologically satisfying about finishing an Event Storming workshop with a huge board covered in carefully arranged sticky notes.
It is visible evidence that work happened.
But the board is not the most important output.
The real output is the change in people’s mental models.
Before the workshop, different participants may have had different interpretations of the same process, different meanings for the same words, and different assumptions about why certain decisions are made.
After a successful workshop, some of those differences should be visible. Some should be resolved. Others should at least be understood.
The team should know more about what it does not know.
That may sound like a strange definition of success, but discovery often works exactly that way.
A successful Event Storming session may leave us with more questions than we started with, but they should be better questions.
We may discover that a supposedly obvious boundary is not obvious at all. We may realize that two teams use the same language for different concepts. We may expose a business rule that had previously existed only in one person’s head. We may even invalidate an architecture we were preparing to build.
Those outcomes are far more valuable than a clean wall.
Event Storming does not fail because the board becomes messy, people disagree, or difficult questions remain unanswered.
Quite often, those are signs that it is working.
It fails when the mechanics continue but discovery stops.
Thanks for reading 🙂