Chapter 6 distilled the whole method into three clauses; the second one is the one this chapter is about: “explore models in a creative collaboration of domain practitioners and software practitioners.” In DDD’s own vocabulary this creative collaboration has a name: knowledge crunching.
The roles are asymmetric on purpose. Stakeholders communicate the business goals and the inputs and outputs of the system; the team captures those as business use cases. Domain experts then work with the development team to produce a useful model that satisfies the needs of the use case. The crunching happens in the middle: developers ask the questions that reveal how the business actually works, and domain experts correct the developers’ naive interpretations.
Knowledge crunching is not an interview and not a documentation phase. It is a continuous, iterative process in which the model is refined, simplified and re-expressed in a shared language as understanding of the problem domain grows. The output of each round is a useful model — one that keeps only what is needed for the problem at hand.
The crunching output becomes the backbone of the ubiquitous language: the model captures the domain experts’ mental models — the entities, their behaviour, cause-and-effect relationships and invariants — and then everyone, including the code, speaks that language.
What the DDD canon does not prescribe is a concrete format for the crunching sessions. This is exactly the gap the lab notes fill: EventStorming is a workshop technique that operationalises knowledge crunching — a structured, repeatable way to run the creative collaboration with domain experts around a wall full of sticky notes.
EventStorming is a low-tech activity in which a group of people brainstorms and rapidly models a business process. It is a tactical tool for sharing business domain knowledge, used as part of the strategic part of DDD — note the apparent paradox: a tactical tool serving strategic design. It was introduced and refined by Alberto Brandolini (“uncle brando”) and the DDD community, and its canonical references are eventstorming.com and Brandolini’s 2013 “Introducing Event Storming” blog post.
The general idea is deliberately simple:
Notice the through-line to Chapter 6: the session starts from domain events — things that have already happened, in the past tense — because events are the most neutral, least technical vocabulary available. Nobody needs to know what a class or a database is to write “Order shipped” on a sticky note. The ubiquitous language is built from the ground up on the business’s own words.
The lab note lists six situations in which EventStorming is the right tool:
The first two use cases are the heart of DDD: building the ubiquitous language for a group that must cooperate on a shared model, and modelling the business process itself — discovering where aggregates end and bounded contexts begin.
Exploring new business requirements keeps all participants aligned on the new functionality and surfaces edge cases that the written requirements never mention; improving an existing process becomes possible because the end-to-end view makes inefficiencies visible.
In legacy modernisation, EventStorming merges the fragmented knowledge held by each participant into a single coherent picture of how the old system really works; in onboarding, the new team member participates in a session and absorbs the domain knowledge by doing, not by reading documentation.
EventStorming is a low-tech activity, and the environment is part of the method:
The low-tech constraint is deliberate: a sticky note forces a short, past-tense, single-concept statement. No UML, no tools to fight with, no code. The medium keeps the group focused on what happened in the business, which is precisely the vocabulary the ubiquitous language needs.
The session is organised as ten steps; during each step, the model is enriched with additional information and concepts:
Step 1 — Unstructured Exploration. The group brainstorms the domain events related to the business domain being explored. A domain event is something interesting that has happened in the business, and it must be formulated in the past tense. All participants grab a bunch of orange sticky notes, write down whatever domain events come to mind, and stick them on the modelling surface. At this early stage there is no need to worry about ordering the events, or even about redundancy.
Step 2 — Timelines. Participants organise the domain events in the order in which they occur in the business domain, starting from the happy path scenario — the flow that describes a successful business scenario. This is also the time to fix incorrect events, remove duplicates, and add missing events if necessary.
Events are the only concept in the process that the domain experts can produce without any help: they have lived the business. Everything else — commands, policies, aggregates — is derived from the timeline of events, which is exactly why the first two steps matter more than they look.
Step 3 — Pain Points. With the events organised in a timeline, the group uses the broad view to identify points in the process that require attention: bottlenecks, manual steps that require automation, missing documentation, or missing domain knowledge. It is important to make these inefficiencies explicit, so that it is easy to return to them as the session progresses, or to address them afterwards. Pain points are marked with rotated (diamond) pink sticky notes.
Step 4 — Pivotal Events. Look for significant business events indicating a change in context or phase. These are called pivotal events and are marked with a vertical bar dividing the events before and after the pivotal event. For example, in the process of making an order, “shopping cart initialized,” “order initialized,” “order shipped,” “order delivered,” and “order returned” represent significant changes. The examinable insight:
Pivotal events are an indicator of potential bounded context boundaries. Every vertical bar on the wall is a candidate seam between contexts — and, later in the course, a candidate seam between microservices.
Step 5 — Commands. Whereas a domain event describes something that has already happened, a command describes what triggered the event or flow of events — the system’s operations — and is formulated in the imperative. Commands are written on light blue sticky notes and placed on the modelling space before the events they can produce. If a particular command is executed by an actor in a specific role, the actor information is added to the command on a small yellow sticky note; the actor represents a user persona within the business domain, such as customer, administrator, or editor. Naturally, not all commands have an associated actor.
Step 6 — Policies. Almost always, some commands end up in the model with no specific actor attached. During this step the group looks for automation policies that might execute those commands: an automation policy is a scenario in which an event triggers the execution of a command — a command is automatically executed when a specific domain event occurs. On the modelling surface, policies are represented as purple sticky notes connecting events to commands. If the command should be triggered only when some decision criteria are met, the criteria are written explicitly on the policy sticky note — for example, trigger the escalate command after the “complaint received” event, but only for VIP customers. If the event and the command are far apart on the wall, an arrow can be drawn to connect them.
The distinction is one of the most frequently examined in the module:
| Domain event | Command | |
|---|---|---|
| Mood | Past tense — something that has already happened | Imperative — what triggered the event or flow |
| Sticky note | Orange | Light blue (actor, when obvious, on a small yellow note) |
| Position | On the timeline, in order | Before the events it can produce |
| Who initiates | Emitted by the business | An actor, a policy, an external system — by the end of step 8, all three cases are covered |
Step 7 — Read Models. A read model is the view of data within the domain that the actor uses to make a decision to execute a command. This can be one of the system’s screens, a report, a notification, and so on. Read models are represented by green sticky notes with a short description of the source of information needed to support the actor’s decision. Since a command is executed after the actor has viewed the read model, on the modelling surface the read models are positioned before the commands.
Step 8 — External Systems. This step augments the model with external systems. An external system is defined as any system that is not a part of the domain being explored. It can execute commands (input) or can be notified about events (output), and it is represented by pink sticky notes. In the lab note’s example, the CRM (external system) triggers execution of the “Ship Order” command; when the shipment is approved (event), it is communicated back to the CRM through a policy.
By the end of this step, the model is complete at the interaction level: all commands should either be executed by actors, triggered by policies, or called by external systems. Nothing on the wall hangs in the air.
Step 9 — Aggregates. Once all the events and commands are represented, the participants can start thinking about organising related concepts in aggregates. An aggregate receives commands and produces events, and is represented as a large yellow sticky note, with commands on the left and events on the right.
Step 10 — Bounded Contexts. The last step of an EventStorming session is to look for aggregates that are related to each other, either because they represent closely related functionality or because they are coupled through policies. The groups of aggregates form natural candidates for bounded contexts’ boundaries.
The session ends where Chapter 6 began: bounded contexts are designed, not discovered — but EventStorming gives the designers raw material. The wall of events, commands, policies and aggregates is a model of the problem space that the team can now slice into contexts, and — as the next chapter shows — into services.
The lab note recommends a legend sum-up: a reference wall, using the sticky notes and labels the session will use, that helps participants remember the colour code. The legend should be visible to all participants during the workshop.
Remote, online and virtual EventStorming is strongly discouraged: it is much less effective than the physical one. When a remote session is unavoidable, possible tools include Miro (an online whiteboard with specific templates for EventStorming) and Lucidchart (which supports EventStorming as well).
The physical format works because of its side channels: seeing everyone’s hands on the notes, overhearing conversations, and the sheer visibility of the wall to the whole group. A video call flattens exactly those channels — the medium is part of the message.
It is the creative collaboration of domain practitioners and software practitioners — the process by which a development team and domain experts jointly produce a model that satisfies the needs of a business use case. It is continuous and iterative: the output is a useful model, simplified as understanding of the problem domain grows, which becomes the backbone of the ubiquitous language.
EventStorming is a low-tech activity in which a group of people brainstorm and rapidly model a business process as a series of domain events represented by sticky notes over a timeline. It was introduced and refined by Alberto Brandolini (“uncle brando”) and the DDD community.
It is a concrete workshop technique — a tactic — used to share business domain knowledge, which is the raw material of strategic design: building the ubiquitous language, modelling business processes, and discovering the boundaries of aggregates and bounded contexts.
(1) To build a ubiquitous language; (2) to model the business process; (3) to explore new business requirements; (4) to recover domain knowledge (especially in legacy modernisation); (5) to explore ways to improve an existing business process; (6) to onboard new team members.
A large modelling space (a wall covered with butcher paper or a large whiteboard), lots of sticky notes of different colours freely available to every participant, and markers. The low-tech constraint forces short, past-tense, single-concept statements in the business’s own vocabulary.
A significant business event indicating a change in context or phase — for example “shopping cart initialized,” “order initialized,” “order shipped.” It is marked with a vertical bar dividing the events before and after it, and it is an indicator of potential bounded context boundaries.
Domain events (orange): something that has happened, in the past tense, laid out on the timeline. Commands (light blue, with the actor on a small yellow note): what triggered the event or flow, in the imperative, placed before the events they produce. Policies (purple, connecting events to commands): an automation scenario in which an event triggers the execution of an actor-less command, possibly with explicit decision criteria. Read models (green): the view of data the actor uses to decide to execute a command, positioned before the commands.
By the end of step 8 all commands must be executed by actors, triggered by policies, or called by external systems (pink notes; any system not part of the domain being explored, which can execute commands as input or be notified about events as output). Step 9 organises related commands and events into aggregates (large yellow notes); step 10 groups related aggregates — by closely related functionality or policy coupling — into natural candidates for bounded context boundaries.
The legend is a reference wall built with the same sticky notes and labels used in the session, visible to all participants during the workshop, so nobody has to remember the colour code. Remote, online or virtual EventStorming is strongly discouraged because it is much less effective; when unavoidable, Miro and Lucidchart offer templates and support.