EventStorming¶

Explore a business domain together by making its meaningful events visible, relating them, and challenging the resulting shared account.

Version: v1 · 2026-10-17 · History
Domain-specific #: 14146
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomain: Domain Driven Design → Computer Science & Software Engineering
Aliases: Event storming, Event-storming

Core Idea¶

EventStorming is a facilitated way for people with different knowledge of a business domain to build and challenge one visible account of what happens there. Participants name meaningful domain events as past-tense happenings, place them in a shared model, and examine how the events relate.^[1] Questions, conflicting descriptions, missing steps, and constraints become discussable because everyone can point to the same event account. The method's creator describes different workshop styles for improving an existing business, envisioning services or business models, and designing software.^[2] These purposes do not define one fixed deliverable.

In a Big Picture workshop, much of the business flow may be arranged along a timeline.^[1] That does not make every process a single left-to-right chain. The creator's Conversational System pattern treats some segments as intrinsically nonsequential and asks the group to show their events together and identify what ends the loop.^[3] Easy LMS used a digital board to investigate its own development work,^[4] while Lowlanders used an in-person workshop to explore a mortgage business line and possible domain boundaries.^[5] Together, these cases show the event-led inquiry under different surfaces and purposes.

Structural Signature¶

A domain question with knowledgeable participants. People bring distinct views of a business activity and a reason to explore it together. Domain experts and technical people often participate, but the named roles are knowledge and inquiry rather than a required job-title list.^[1]^[5]
Meaningful domain events. Participants externalize happenings that matter to the domain in business language, ordinarily as past-tense facts. The event is the starting unit, not a screen, table, department, or preselected solution.^[1]^[5]
A shared visual account. Events are placed where everyone can inspect and relate them. Ordering is useful where one event precedes another; branches, loops, and unordered segments remain possible.^[1]^[3]
Facilitated scrutiny. Participants compare perspectives, ask what is missing or disputed, revise the model, and mark unresolved questions or constraints for later work.^[1]^[4]^[5]

Remove the event-led shared account and the activity becomes a general discussion. Remove the joint scrutiny and a solitary event list may resemble the output without being an EventStorming workshop. Commands, actors, policies, systems, hotspots, pivotal events, swimlanes, and context maps can deepen a particular style; none is a universal prerequisite.^[2]^[6]^[1]

What It Is Not¶

EventStorming is not event sourcing. An event-sourced system stores events so application state can be reconstructed; a workshop can draw a business flow without building or specifying such a runtime. Nor is it identical to event-centered data modeling, which makes events primary nodes of a persistent schema and derives entity state from them. The workshop makes people jointly inspect an event account; it does not require a particular persistence architecture.

It is also narrower than business-process modeling as a whole. A process can be modeled with many notations or from an analyst's observations. The EventStorming identity requires collaborative elicitation and challenge around domain events. A paper wall, orange notes, or a diagram with event labels can be evidence of a particular session, but those visible materials alone do not prove that the method took place. Remote digital work is explicitly supported by the creator and documented by Easy LMS.^[2]^[4]

Scope of Application¶

The literal home is collective exploration of a business domain in software and organizational work. The creator describes styles for examining an existing business line, testing a new business idea, designing services, and designing event-driven software.^[2] The chosen purpose changes who attends, how much detail the group adds, and what they do with the model afterward.

Easy LMS used a remote board to clarify its own development workflow and identify missing process steps.^[4] In a financial enterprise described under the pseudonym Lowlanders, a facilitator brought stakeholders together to map mortgage-domain events and investigate potential boundaries for teams and software.^[5] These are different objects and purposes under the same event-led workshop relation. A report by Thoughtworks names an Event-Storming exercise in Workrise's domain-boundary effort, but it does not publish the particular event cards or workshop conversation; it supports a limited named use, not a third detailed example.^[7]

Clarity¶

Ask first: Which meaningful happenings did participants write down, and what changed when they compared them? A workshop label or photograph of sticky notes is weaker evidence than an account of the event descriptions, their relations, and the questions they exposed. At Lowlanders, apparently similar words such as “pieces” held different meanings in mortgage contexts; the event conversation made that ambiguity visible.^[5] At Easy LMS, comparing notes along the development-process flow surfaced duplicate descriptions, disputed order, branches, and hotspots.^[4]

Do not use a tidy timeline as a false recognition test. It is often a working surface for Big Picture or process work, not a guarantee that the domain itself is sequential. A negotiation loop may need to be represented as an unordered conversational segment with an exit event.^[3]

Manages Complexity¶

Different participants know different parts of a business flow. Putting their event descriptions on one surface lets them locate gaps and clashes without first agreeing on a complete vocabulary or software architecture. Brandolini's Big Picture account deliberately begins with independent event writing, then uses ordering and walkthroughs to make disagreements and omissions visible.^[1] This reduces the cost of discussing an otherwise scattered set of local accounts; it does not remove the need to investigate disputed facts.

The shared surface also limits what can be claimed. A hotspot marks uncertainty; it is not itself a resolution. A context boundary suggested by a cluster of events is a design hypothesis for later work, not a boundary automatically proved by note placement.^[1]^[5]

Abstract Reasoning¶

Begin with a domain question and invite the people who can supply different parts of the answer. Have them name events in domain language, then put those events where others can inspect them. Relate events in time or by trigger where that relation is meaningful. Ask which descriptions are duplicates, which only seem synonymous, which events are missing, and what exceptions break the emerging story. Mark an unresolved point instead of making a premature agreement. The creator's account describes that progression for Big Picture work; other styles can add different notation later.^[1]^[6]

The reasoning move is to use an event as a testable point of contact between perspectives. At Lowlanders, one product owner disputed another's walkthrough of a swimlane; the facilitator kept the disagreement visible when the group could not settle it.^[5] That is a more informative model than one that erases a conflict to preserve a clean sequence. For a conversational segment, ask what event terminates the loop rather than manufacturing an arbitrary order for every exchange.^[3]

Knowledge Transfer¶

Within the home domain, the method transfers when a new group can elicit meaningful domain events into a shared model and challenge that model together. Easy LMS applied it to a software team's development process and documented that process,^[4] while Lowlanders applied it to a mortgage business line and later used the result to examine possible domain boundaries.^[5] The event-led inquiry remains recognizable while its follow-through changes.

Outside this domain, the words “events on a timeline” can be a useful analogy but do not by themselves establish EventStorming. The imported name is warranted only if participants are jointly investigating a domain through its meaningful happenings and using the visible account to expose competing knowledge, gaps or constraints.

Examples¶

Remote process clarification at Easy LMS¶

Easy LMS invited developers from two teams to map their changing internal development process on a shared Miro board. They wrote past-tense events such as a code repository being created and code being deployed, then discussed their placement on a timeline. Duplicate events, branches, and uncertainties became visible; the group marked hotspots and later added commands, data, systems and policies. The authors report a clearer account of their current process and missing pieces.^[4] This is a first-person process-improvement account, not a controlled measurement of improved performance.

Mapped back: participants with different process knowledge → development events → remote shared flow → discussion of order, duplicates and hotspots → optional process documentation. The digital surface demonstrates that paper is an implementation choice.

Mortgage-domain exploration at Lowlanders¶

In a Big Picture session at Lowlanders, business and technical participants wrote events including a mortgage request received, a mortgage application passed, a tender signed, and a declaration rejected. They placed their perspectives on a common surface, organized parts of the flow, and questioned words that meant different things in different contexts. One disagreement between product owners remained unresolved and was marked as a constraint. The facilitator later used the workshop's emergent structure to draw a context map for discussion of possible boundaries.^[5]

Mapped back: cross-functional mortgage knowledge → named mortgage events → shared in-person model → ambiguity and unresolved disagreement made visible → optional boundary-design follow-through. The context map is an interpretation after the event work, not a mandatory product of every EventStorming session.

Structural Tensions¶

Independent elicitation versus a coherent shared account. Letting participants write before negotiation preserves local knowledge and can reveal that identical words hide different business meanings. The group then needs enough ordering and walkthrough to see how the events connect. Pushing consensus too early can erase useful differences; insisting on a single settled path can waste effort or misrepresent a genuinely conversational process. Brandolini's workshop account preserves divergent notes before enforcing a Big Picture timeline, while the creator's Conversational System guidance permits unordered segments.^[1]^[3] These are method-design pressures, not experimentally measured effects. Diagnostic: Which disagreement needs discussion now, which should remain marked, and which event relation should stay partial or unordered?

Structural–Framed Character¶

EventStorming is strongly framed on the structural–framed spectrum: it has a recognizable event-led structure, but its identity remains a named human workshop method rooted in domain-driven design. Its evaluative weight lies in whether participants learn enough about the domain to make better questions and decisions, not in a guarantee of software quality or business success. Its institutional origin is Brandolini's EventStorming practice and its named workshop styles.^[2]^[1] Its human-practice dependence is high: participants' knowledge, facilitation, language and willingness to disagree shape what the shared account reveals.^[5]

Vocabulary portability is bounded. Event, timeline and workshop are common words, but the name EventStorming carries an event-first collaborative procedure. Import versus recognition therefore asks whether the new case actually shows that procedure, rather than merely displaying colored notes or adopting a fashionable label. Its character: a strongly framed specialist method whose repeatable event-led inquiry is structural, while its business-domain object and human facilitation keep the named identity within its home practice.

Structural Core vs. Domain Accent¶

The thin core is: people with partial knowledge externalize meaningful happenings, relate them in a common view, and use discrepancies to improve a shared account. Whether that collaborative-inquiry skeleton recurs as one literal pattern outside business settings remains a future-prime question. Representation describes the shared event account as one internal part; representation alone does not supply the workshop method. The domain accent is constitutive, not decorative. These are domain events in business language; the questions concern processes, service behavior, organizational boundaries, or software design; a facilitator makes the differences discussable.^[1]^[2]

The Easy LMS and Lowlanders cases vary in surface, object and goal, but both satisfy that role map.^[4]^[5] Their two applications remain within business/domain exploration. A future Prime would need independently documented unlike nonbusiness settings in which people jointly elicit meaningful events, relate them in a shared model, and use disagreement or gaps to revise the account, with the same failure tests holding when business and DDD vocabulary is removed. Merely importing the word EventStorming into a historical timeline, clinical log or group brainstorm would be analogy or borrowing, not affirmative evidence. These sources do not establish that broader recurrence.

This entry is part of Representation.

Representation is an internal part: the visible event account maps selected business happenings into a shared medium for interpretation and revision. Event-Centered Modeling makes happenings primary nodes in a data schema and derives entity state from those nodes. EventStorming may share attention to events, but a workshop need not create that schema or compute state projections. A Shared Mental Model may be one outcome of the conversation, but that outcome alone does not specify the event-led method. Business-Process Modeling is a broader activity that can use many methods; EventStorming also serves service and software-domain exploration. Collaboration describes the joint work among participants, while EventStorming adds its domain-event elicitation and facilitated scrutiny.

Relationships to Other Abstractions¶

Current abstraction EventStorming Domain-specific

Parents (1) — more general patterns this builds on

EventStorming is part of Representation Prime

EventStorming contains a shared event representation that participants build and challenge as an internal part of the workshop.

Hierarchy path (1) — routes to 1 parentless root

EventStorming → Representation → Abstraction

Neighborhood in Abstraction Space¶

EventStorming sits in a sparse region of the domain-specific corpus (99^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2721 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-17

Not to Be Confused With¶

Event sourcing: an application persistence architecture, not the collaborative discovery workshop.
Event-centered modeling: a representation pattern with event-primary schema wiring, not necessarily facilitated event elicitation.
Business-process modeling as a whole: a wider activity with multiple methods and notations.
A fixed sticky-note protocol: the creator supports different styles, remote work and incremental notation.^[2]^[6]
A guaranteed timeline or bounded-context output: some segments are nonsequential, and boundaries require later interpretation.^[3]^[5]
The seed's e-commerce and insurer sketches: hypothetical illustrations without observed-case documentation in the inspected source set.

References¶

[1] Alberto Brandolini, “Discovering Bounded Contexts with EventStorming”, especially “Enter EventStorming” and “Structure of a Big Picture workshop,” Steps 1–4 and Extra steps. Full creator-authored essay directly inspected. Big Picture steps are not universal requirements for all styles. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m

[2] EventStorming, “EventStorming”, opening description, Styles (Improve, Envision, Explore, Design), and Services (Onsite and Remote). Full creator-controlled page directly inspected. The styles describe supported purposes, not a claim that every session has every output. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g

[3] EventStorming, “Conversational System”, opening problem and “Therefore.” Full creator-controlled page directly inspected. It permits a nonsequential segment within an event-modeling workshop; it does not make an ordinary negotiation a complete workshop. registry ↩a ↩b ↩c ↩d ↩e ↩f

[4] Easy LMS, “How we use EventStorming to make our processes clear”, 7 September 2021, sections “Modeling our development process,” “Chaotic exploration,” “Enforcing the timeline,” “Enriching the events,” and “Experiment completed successfully.” Full first-person practitioner account directly inspected; reported clarity and gaps are the authors' observations, not controlled outcome measurements. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h

[5] Kenny Baas-Schwegler, “Towards Autonomous Aligned Teams with Domain-Driven Design”, Agile Alliance experience report, §§4.1–4.5 and 5. Full first-person workshop account directly inspected; Lowlanders is a pseudonym. Named mortgage events, collaborative timeline, terminology disagreements, constraints, and later context mapping are stated in the report. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m

[6] EventStorming, “Patterns”, preface and “Incremental notation.” Full creator-controlled page directly inspected; it presents context-sensitive guidelines rather than one required list. registry ↩a ↩b ↩c

[7] Thoughtworks, “Workrise growth”, “Domain-driven design and a new tech strategy.” Full first-person client account directly inspected. It names an Event-Storming exercise and a domain-boundary outcome but does not publish its event cards or workshop mechanics. registry ↩