Event Storming at Scale: Why AI Changes the Discovery Game
Using AI to Keep Event Storming Results Alive and Accurate
Event Storming was never supposed to be a methodology. Alberto Brandolini created it as a workshop format, a way to get domain experts and engineers in the same room, cover a wall with sticky notes, and build a shared understanding of a business domain faster than any requirements document ever could. For a while, it works exactly like that.
Teams walk out of a two-day workshop with a clearer picture of their domain than they gained from months of sprint planning sessions, backlog refinement meetings, and architecture reviews. Ambiguous terminology becomes visible. Business rules that lived only in people’s heads finally get written down. Different teams start speaking the same language.
Then the workshop ends. The sticky notes come down. Someone takes a few photos. A Miro board is created. A Confluence page appears. The domain model is documented, shared, and celebrated, then the domain changes.
A new regulatory requirement arrives. A business process is modified. A new integration introduces behaviors nobody discussed during the workshop. An edge case appears in production for the first time. Six months later, the model no longer represents the domain as it exists today. It represents the domain as it was understood on the day the workshop ended. This is not a criticism of Event Storming. It is simply what happens when a static artifact meets a constantly evolving business.
Most teams accept this drift as inevitable. The workshop produces a snapshot of reality, and that snapshot gradually becomes less accurate over time. The larger and more complex the domain becomes, the faster that drift happens.
What has changed recently is that AI can participate in the discovery process itself. It can analyze requirements, challenge assumptions, surface missing scenarios, review historical incidents, and continuously compare documented models against information scattered across tickets, specifications, support conversations, and production systems.
AI does not eliminate the need for Event Storming. If anything, it makes collaborative discovery even more valuable. What it changes is the amount of information that can be brought into the room and the ability to keep the resulting model alive after the workshop is over.
Why Event Storming Often Fails in Production Teams
The failure mode is rarely the workshop itself. Well-facilitated Event Storming sessions produce valuable insights. The challenge begins after the workshop, when the model has to survive contact with a real production environment.
The first problem is completeness. Teams rarely forget the happy path. They forget the scenarios that happen occasionally, the provider outage that occurs twice a year, the duplicate import that appears during a synchronization failure, the edge case that only surfaces when multiple systems disagree about the current state of a business process.
These situations are often understood by experienced engineers and operations teams, but they never make it onto the wall because nobody thinks about them during a workshop. They are considered obvious until a production incident proves otherwise.
The second problem is consistency. Different groups often use the same words to mean different things. Everyone leaves the workshop believing they agree because the terminology sounds familiar. The disagreement only becomes visible later when systems interact.
In one domain, a term like “active listing” may simply mean visible to customers. In another, it may mean synchronized from an external provider, approved internally, and eligible for marketing distribution. Both teams use the same phrase while describing different realities.
Event Storming is designed to uncover these misunderstandings, but identifying them depends heavily on the experience of the participants and the facilitator. The third problem is longevity. The model produced during the workshop is documented, shared, updated once or twice, and eventually forgotten. Meanwhile, the business keeps moving.
New policies appear. Existing workflows evolve. Aggregates grow beyond their original boundaries. Teams split responsibilities across services. Regulatory requirements introduce new constraints. The documented model remains frozen while the actual domain continues to change.
Eventually, the gap becomes large enough that engineers stop trusting the documentation. At that point, the model serves as historical context rather than an accurate representation of the business.
These three problems, completeness, consistency, and longevity, are where AI can provide meaningful assistance. Not by replacing domain experts or replacing Event Storming workshops, but by expanding the information available during discovery and helping teams keep their models aligned with reality long after the sticky notes have disappeared.
The MLS Platform: A Running Example
To make the discussion concrete, let’s use a Multiple Listing Service (MLS) platform as a running example.
Real estate systems are deceptively complex. At first glance, they appear to be little more than property listings and search functionality. In reality, they contain a dense network of business rules, compliance requirements, third-party integrations, and operational workflows that evolve continuously over time. They are exactly the kind of domain where an Event Storming workshop can produce an elegant model that later struggles to explain what actually happens in production.
Imagine a team running an Event Storming workshop to model the lifecycle of a property listing. The room contains the right people: product managers, engineers, compliance specialists, and experienced real estate professionals. After two days of discussion, the wall contains a clean sequence of events: PropertyListed, OfferSubmitted, InspectionScheduled, InspectionCompleted, ContractSigned, ClosingScheduled, and DeedTransferred. The model is coherent, well-named, and easy to understand. Everyone leaves the workshop feeling confident that they have captured the domain.
The problem is that they have mostly captured the story of what normally happens.
Real production systems spend a surprising amount of time dealing with situations that nobody considers unusual but rarely thinks to mention during a workshop. A listing may be withdrawn temporarily while repairs are completed. An accepted offer may return to negotiation after an inspection reveals structural issues. A property may need to be re-disclosed because of jurisdiction-specific regulations. Multiple providers may report conflicting statuses for the same listing. An agent’s license may expire in the middle of a transaction. A closing may be delayed because a lender requires an additional appraisal.
None of these scenarios are particularly rare. Anyone who has spent time working in real estate would recognize them immediately. The challenge is that domain experts naturally describe how the business usually operates. They focus on the primary workflow because that is the easiest story to tell. The exceptions, compliance issues, synchronization failures, and operational headaches that consume engineering time often remain implicit.
As a result, the workshop output is usually accurate, but incomplete. The model reflects the collective memory of the people in the room, not necessarily the full complexity of the domain. This is where AI begins to create value. Not because it understands the business better than the people participating in the workshop, but because it can systematically explore information that would otherwise remain scattered across codebases, documentation, incident reports, support tickets, and operational history.
AI as a Domain Discovery Partner
The most practical use of AI in Event Storming is not generating domain models automatically. It is increasing the coverage of the discovery process.
Most organizations are not modeling a greenfield business. They already possess years of accumulated knowledge distributed across source code, support tickets, compliance documents, architectural decision records, operational runbooks, and internal documentation. The problem is that nobody has enough time to review all of this material before a workshop begins, AI can.
Before an Event Storming session starts, a language model can analyze existing artifacts and surface candidate domain concepts for discussion. It can identify descriptions of state changes, recurring business operations, and patterns that appear repeatedly across documentation and support conversations. More importantly, it can highlight areas where the documented understanding of the domain appears incomplete or inconsistent.
For an MLS platform, this might involve analyzing support tickets, compliance requirements, and existing services before the workshop begins. Instead of starting with an empty wall, the team arrives with a collection of candidate events that deserve examination. Examples might include ListingExpired, ListingReactivated, AgentLicenseVerificationRequested, ListingComplianceViolationDetected, DualAgencyConsentObtained, or AppraisalWaiverSubmitted. Some suggestions will inevitably be wrong. Others may represent implementation details rather than domain concepts. That is not a problem. The objective is not to generate perfect answers. The objective is to surface possibilities that deserve discussion.
AI is particularly valuable when searching for missing scenarios and edge cases. One surprisingly effective exercise is simply asking the model what could go wrong. Given a listing workflow, it will often generate dozens of situations that never surfaced during the workshop: provider synchronization failures, conflicting updates from different systems, missing disclosures, duplicate property records, regulatory violations, or unexpected state transitions. Experienced domain experts usually recognize these situations immediately. The value comes from surfacing them systematically rather than relying on somebody to remember them during a two-day session.
The same principle applies to commands and policies. Once a set of domain events exists, AI can suggest candidate commands that trigger those events and policies that connect them. It can identify events that appear to lack a triggering intention or business rules that seem to require a downstream response but have not been modeled. These suggestions are not decisions. They are prompts for further exploration.
Aggregate boundaries and bounded contexts benefit from the same approach. By analyzing how concepts change together, which data is frequently accessed as a unit, and which operations appear to require strong consistency guarantees, AI can propose potential aggregate boundaries. Likewise, it can cluster related concepts and suggest bounded contexts based on language, operational responsibilities, and rates of change. Some of these suggestions will prove useful. Others will be completely wrong. Both outcomes are valuable because they force explicit discussion.
This distinction is important. The value of AI in domain discovery is not correctness. The value is coverage. A facilitator supported by AI can surface more candidate concepts, more edge cases, more potential boundaries, and more hidden assumptions than a facilitator relying solely on memory and workshop discussion. The domain experts still make every meaningful decision. AI simply increases the likelihood that those decisions are made consciously rather than accidentally.
Where AI Stops and Domain Expertise Begins
There is a tempting mistake teams make when introducing AI into domain modeling. They feed documentation, source code, tickets, and diagrams into a language model, receive a list of suggested events, commands, aggregates, and bounded contexts, and begin treating those suggestions as conclusions. That is where trouble starts. AI is very good at finding patterns. It is not particularly good at understanding why those patterns exist.
A language model can tell you that two operations frequently happen together. It can identify data that is often modified as a unit. It can recognize relationships between concepts that appear repeatedly across code and documentation. What it cannot reliably discover are the business invariants that exist outside the system itself.
In many organizations, the most important business rules are not fully documented. They exist because of regulatory requirements, contractual obligations, historical decisions, or operational experience accumulated over years. Sometimes the only people who understand them are the domain experts who have lived with the system long enough to know what happens when those rules are violated.
Consider a real estate platform operating across multiple jurisdictions. A compliance workflow may exist because of a specific regulatory interpretation negotiated years ago. The resulting business rule influences how listings move through the system, but the reasoning behind it may never appear in the codebase. The software reflects the rule. It does not explain the history behind it. An AI model analyzing that system can observe behavior. It cannot reliably explain intent.
This is why AI should never be viewed as a replacement for domain expertise. The most effective workflow is one where AI generates candidates and domain experts make decisions. The model surfaces potential events, policies, edge cases, aggregates, and context boundaries. The experts review them, reject some, refine others, and occasionally discover something important that had previously gone unnoticed.
In practice, this changes the nature of the work. Instead of spending hours trying to remember every possible exception, participants spend their time evaluating a prepared set of candidates. The discussion becomes more focused because the room is reacting to concrete suggestions rather than attempting to generate everything from scratch.
AI also has a tendency to produce technically correct but business-poor language.
Given enough context, it will happily suggest events such as StatusChanged, RecordUpdated, or DataModified. These names may describe what happened from a technical perspective, but they say very little about the business itself.
Domain experts naturally push the language toward something more meaningful. A generic StatusChanged may become ListingWithdrawnPendingSellerRepairs. A RecordUpdated may become OfferRejectedAfterInspectionFindings. The difference is subtle but important. One describes a database operation. The other describes something the business actually cares about. That distinction remains a human responsibility.
The most useful way to think about AI in Event Storming is not as a facilitator or a co-designer. It is closer to a research assistant that has read every available artifact and can report back with observations. It can surface patterns, identify inconsistencies, and generate possibilities. What it cannot do is determine which possibilities matter.
That responsibility remains exactly where it has always belonged: with the people who understand the domain.
Turning Event Storming into Living Documentation
Even when an Event Storming workshop is successful, another challenge appears almost immediately. Keeping the model current.
Most teams invest significant effort into creating a domain model and very little effort into maintaining one. The workshop ends, the diagrams are documented, and everyone agrees they should be kept up to date. Then feature work resumes, priorities shift, deadlines appear, and model maintenance quietly falls to the bottom of the backlog. Six months later the model still exists, but nobody fully trusts it. This is where AI may ultimately provide more value than it does during the workshop itself.
Instead of treating the domain model as a static artifact, teams can use AI to continuously compare the documented model against signals coming from the actual system. Support tickets, incident reports, event logs, new features, compliance changes, and operational documentation all contain information about how the domain is evolving. The goal is not automatic model updates. The goal is drift detection.
Imagine an MLS platform where a new category of support request begins appearing repeatedly. Sellers are asking what happens when an agent loses their license during an active transaction. The issue appears often enough that support teams have developed informal procedures to handle it, but the scenario does not exist anywhere in the domain model. Traditionally, this gap might remain invisible for months.
An AI-assisted review process could identify the pattern much earlier. The model notices a recurring workflow appearing in support tickets and operational conversations that has no corresponding representation in the domain model. It flags the discrepancy for review. The important part is what happens next.
A domain expert validates whether the scenario is legitimate. Engineers determine how the system currently behaves. The team discusses whether new events, commands, policies, or aggregates are required. The model is updated deliberately rather than accidentally.
This is fundamentally different from the approach most teams use today, which is simply allowing the model to become outdated until nobody relies on it anymore.
AI does not solve the maintenance problem by itself. What it does is make maintenance practical. Instead of asking teams to periodically re-examine an entire domain, it highlights specific areas where reality and documentation appear to be diverging. That is a much easier problem to solve.
Over time, the result is a domain model that evolves alongside the business rather than falling behind it. Changes become explicit. New concepts are introduced intentionally. The language shared between engineers and domain experts remains aligned with the reality of the system. That outcome has always been one of the central goals of Domain-Driven Design.
Event Storming remains one of the best tools available for creating that shared language.
AI simply makes it easier to keep that language alive.
Conclusion
The biggest challenge with Event Storming has never been the workshop itself. Most workshops succeed. The real challenge begins after the workshop ends, when the domain starts changing and the model slowly drifts away from reality.
Historically, teams have accepted that drift as inevitable. The workshop produces a snapshot of the business, and over time that snapshot becomes less accurate. New workflows emerge. Edge cases accumulate. Business rules evolve. The documentation remains frozen while the domain keeps moving. AI changes that dynamic.
Not because it understands the business better than the people responsible for it, but because it can process far more information than any individual participant could reasonably review. It can identify patterns across tickets, documentation, code, support conversations, and operational history. It can surface candidate events, uncover missing scenarios, and highlight areas where the documented model no longer reflects the behavior of the system.
What it cannot do is make domain decisions. It cannot determine which business invariants matter. It cannot explain why a rule exists. It cannot replace the judgment of a domain expert who understands the consequences of getting the model wrong.
The most effective approach is therefore not AI-driven modeling. It is AI-assisted discovery. The workshop still matters. The conversations still matter. The sticky notes still matter. Domain experts remain responsible for every meaningful decision. The difference is that the team is no longer relying entirely on memory, intuition, and whatever happened to come up during a two-day session.
The wall still represents the domain. Now there is simply something helping ensure that the wall continues to reflect reality long after the workshop is over.
Event storming was always about surfacing the questions nobody wrote down, so it’s a good fit for AI to accelerate. The risk I’d watch is the model generating plausible events that smooth over the real disagreements in the room. The friction between domain experts is the signal, not noise to optimize away.