# Preparation - Huge whiteboard - Food and water - Sticky notes and markers - No tables or chairs - In-person: up to 10 participants; online: limit to 5 # Overview - Orange: **[[Domain Events]]** - White: **Pain Points** tag Domain Events - Light blue: **[[Commands]]** → Domain Events - Yellow: **[[Actors]]** → Commands - Purple: **[[Policies]]** / Notifications connect Domain Events to Commands or External Systems - Green: **[[Read Models]]** / Materialized Views → Actors (with Commands) - Pink: **[[External Systems]]** → Commands (or nothing) # Use-cases - Kickoff an [[Event Sourcing]] architecture - Build the [[Ubiquitous Language]] - Model the [[Business Domain]] to capture the process and requirements - Recover domain knowledge from domain experts - Find way to improve existing processes - Onboard new team members # Process ## Step 1: Brain-storm (partial, stepwise) outcomes as events - Orange stickies Capture [[Domain Events]] only; More [[Domain Events]] might be found later. Keep going until there is a significant slow-down in the process. ## Step 2: Order events chronologically Order domain events by time, starting with the happy path. Add different paths as branches, possibly connected by arrows. ## Step 3: Surface pain-points - White notes Mark bottlenecks, manual steps that should be automated, missing data/documentation/knowledge in the domain process with white sticky notes (placed in diamond shape, if possible). More pain points might be discovered in later steps. ## Step 4: Identify pivotal events Identify potential context boundary events (“order shipped”) and mark them by separating the event process with black lines crossing through the pivotal event post-it, or adding space around that note, or otherwise highlight that note. ## Step 5: Prefix chains of events with triggers and roles - Light blue notes - Yellow notes Identify [[Commands]] (in light blue) that trigger a flow of events (“submit order”) and place them in front of the event chain they trigger. If a Command has an Actor in a specific role, tag the command with an additional yellow sticky note and with the Actor’s role (“customer”). Only care about adding Actors where it is obvious. ## Step 6: Identify automation triggers - Purple notes Find events that trigger the execution of a command. That is, opportunities where a command can be executed automatically when that event occurs. Connect the event and the command it triggers with a purple Policy post-it, possibly using arrows to connect the event and the command. [[Policies]] have the policy’s name and possibly the condition under which the automation would trigger (“only for VIP customers”). ## Step 7: Identify views needed for decision-making - Green notes Prefix Commands with [[Read Models]] that Actors would need to make the decision to execute that Command. These views can be on-screen, a report, a notification, or something similar. The green sticky note can hold a short description of the source of information and/or the name of the Read Model. ## Step 8: Add external dependencies - Pink notes Identify [[External Systems]] that either trigger commands or receive notifications when certain events occur. If the [[External Systems]] execute the Command, the note is placed before the Command. If it is notified by a Domain Event, it should be connected by a purple Policy note. ## Checkpoint At this point, all Commands should be executed by Actors, or triggered by Policies, or called by External Systems. ## Step 9: Group commands and their events Organize related commands and their events into [[Aggregates]]. ## Step 10: Identify context boundaries [[Context Boundaries]] are typically drawn around Aggregates that are connected to other Aggregates only by Policy/Notification connectors that are not in chronological order and therefore only connected by long arrows. # Reference ![Reference](Event%20Storming%20Reference.png) # Links - https://www.eventstorming.com/ - [Modelling Reactive Systems with Event Storming and Domain-Driven Design](https://blog.redelastic.com/corporate-arts-crafts-modelling-reactive-systems-with-event-storming-73c6236f5dd7)