How does the output of an Event Storming workshop feed into strategic design activities like Context Mapping and subdomain classification (core/supporting/generic), and when would you deliberately choose NOT to run Event Storming for a discovery effort?

## Raw material for strategic design Event Storming's output is raw material, not a finished strategic-design artifact, and understanding exactly how it gets refined into subdomain classification and Context Mapping — and when the exercise isn't worth running at all — is what separates using it as a checkbox ritual from using it as a genuine input to architecture decisions. ## Subdomain classification Subdomain classification is Eric Evans's strategic-design idea of sorting parts of the business into - **core** — the complex, differentiating logic that is the actual reason the company competes and wins, worth heavy custom investment and the best engineers; - **supporting** — necessary but not differentiating, still somewhat custom, lower investment priority; - **generic** — solved problems common to many businesses (authentication, payroll tax, email delivery) that should be bought or adopted off the shelf rather than reinvented. An Event Storming board makes this classification visible rather than theoretical: | What the board shows | What it signals | |---|---| | clusters of events with dense, contested detail, frequent hotspots, and heavy domain-expert engagement during the session | almost always where the real competitive complexity lives — people argue about it because it matters and because it's genuinely intricate, which is exactly the signature of a core subdomain | | Conversely, sections of the timeline where the group breezes through with immediate agreement and little debate, or where someone says "oh, that's just standard invoicing, every company does it the same way" | signatures of a generic subdomain best served by an existing product rather than a bespoke design | ## Context Mapping Context Mapping is the complementary practice of explicitly documenting the relationships between bounded contexts once they're identified — is it - a **Shared Kernel** (two contexts deliberately sharing a small common model), - a **Customer-Supplier** relationship (one context's team depends on and can influence another's roadmap), - a **Conformist** relationship (one context just accepts the other's model as-is with no negotiating power), - or does an **Anti-Corruption Layer** sit at the boundary translating between two models that must stay independent? A hotspot on the Event Storming board — the note marking where two groups disagreed or used the same word differently — is frequently the literal location where one of these relationships needs to be made explicit. If Sales and Fulfillment both used "Customer" to mean different things and that hotspot never gets resolved into an explicit translation, the eventual codebase inherits the ambiguity as a bug generator; Context Mapping is the deliberate act of turning that hotspot into a documented, intentional boundary decision instead. ## When to deliberately skip it The case for deliberately not running Event Storming rests on the same logic that explains why it works when you do run it: its entire value proposition is cheaply surfacing unknown unknowns and reconciling disagreement across many people's separately-held mental models. That value is highest exactly when the domain is genuinely under-documented, spread across many heads, and likely to contain hidden contradictions. It correspondingly shrinks toward zero in a few identifiable situations. 1. **First**, when the domain is already accurately known and documented by one or a few reliable sources — a stable legacy system with a long-tenured architect who can describe every process from memory and whose account nobody credibly disputes — the marginal knowledge a multi-day, many-person workshop would surface may not be worth the collective cost of everyone's time; a smaller working session with that architect and a couple of developers gets nearly the same result far more cheaply. 2. **Second**, for a subdomain that's already been identified as purely generic, the better use of time is usually studying how existing off-the-shelf solutions model the problem, rather than reinventing that model from scratch through group discovery; the workshop format earns its cost on complexity and disagreement, neither of which a well-understood generic problem has much of. 3. **Third**, under genuine time pressure with a small, already-aligned team, the facilitation overhead of a proper multi-hour session may simply not be affordable, and a lighter-weight technique gets "good enough" discovery faster. ## Seeing the call made in practice A concrete case: a company evaluating whether to build custom pricing/discount logic (a candidate core domain, given hotspots and heavy debate during their Big Picture session about edge cases like loyalty-tier stacking) versus their existing tax-calculation module (which the same session breezed through in ten minutes because "it's just what the tax API returns") used exactly this signal to justify investing senior engineering time in the pricing engine while deliberately keeping the tax module a thin wrapper around a bought SaaS provider — a decision the Event Storming session made visible rather than requiring a separate strategic debate.