What It Is

Event Storming is a highly interactive workshop method designed to rapidly map business processes through collective intelligence. Participants use differently colored sticky notes to represent elements like events, commands, and aggregates, building timelines on walls to reveal the full picture of system behavior and user interactions. This approach not only accelerates knowledge transfer but also exposes hidden assumptions and dependencies, laying a clear foundation for subsequent technical implementation.

Origins and Key Figures

Event Storming was first introduced by Italian software engineer Alberto Brandolini in 2012, inspired by Domain-Driven Design (DDD) and agile practices. Brandolini observed inefficiencies in traditional modeling tools when dealing with complex business scenarios, leading him to design this lightweight, visual collaborative approach. Key figures include promoters like Eric Evans (founder of DDD), whose ideas provide theoretical support, emphasizing an event-centric understanding of domain logic.

How to Use

1. Prepare materials: Ensure sufficient wall space, various colored sticky notes, markers, and a timer; invite cross-functional members from business, technology, etc.
2. Identify domain events: From a business perspective, write "happened" events on orange sticky notes, e.g., "Order Created," and arrange them chronologically on the wall.
3. Add commands and aggregates: Use blue sticky notes for commands triggering events (e.g., "User Submits Order") and yellow sticky notes for aggregates (e.g., "Order"), connecting related elements.
4. Mark hotspots and issues: Use red sticky notes to flag controversies or unknowns, e.g., "Payment Failure Handling Unclear," to foster team discussion and clarification.
5. Refine models and actions: Based on the visualization, define bounded contexts, create user stories, or make architectural decisions, ensuring each step has verifiable output criteria.

Case Study

Background and constraints: An e-commerce company plans to upgrade its order processing system, with existing workflows involving multiple teams for inventory, payment, and logistics, but messy interfaces cause high delays.

Time is tight, requiring requirements梳理 within two weeks, and the budget is limited, preventing extensive documentation work.

Problem diagnosis: The team found that order statuses were often out of sync, and customer service couldn't track root causes in real time.

Business logic was scattered across legacy modules, lacking a unified event flow view, leading to chain errors when fixing bugs.

Phased actions: Phase one involved an Event Storming workshop, gathering representatives from product, development, and operations to build a full event flow from "User Browses Product" to "Order Completed" on the wall.

Phase two identified key aggregates like "Inventory Item" and "Payment Transaction," marking dependencies with sticky notes.

Phase three addressed red hotspots such as "Refund Process," developing detailed sub-event flows and assigning responsible teams for follow-up.

Results comparison: After the workshop, average order processing time reduced from 48 hours to 12 hours, and system error rates dropped by 40%.

Team communication efficiency improved, with cross-departmental meetings decreasing by 50%, as the visual model provided a common reference point.

Retrospective and transferable insights: Early involvement of domain experts significantly enhances event accuracy, applicable to other complex integration projects.

Strengths and Limitations

Strengths: Event Storming fosters cross-functional communication, breaking down information silos and aligning business and technical language.

The visual format reduces cognitive load, helping teams quickly grasp the system overview, especially useful for onboarding new members.

It is low-cost with high returns, requiring only basic tools to produce actionable insights and accelerate decision-making.

Limitations: It heavily depends on the facilitator's skills; lack of experience may lead to divergent discussions or time waste.

For very large-scale systems (e.g., hundreds of events), wall space may be insufficient, requiring split sessions that add complexity.

Applicability boundary: Best suited for exploratory projects or early refactoring stages, not recommended for modeling simple, stable workflows.

Potential risks and mitigation: Risks include participant resistance or outputs not being followed up; mitigation strategies involve setting clear goals, assigning action items, and regular reviews.

Trade-off suggestion: When time is tight, prioritize focusing on core event flows over perfect details, balancing depth and breadth.

Common Questions

Q: How to determine if Event Storming is suitable for a current project?

A: Assess if the project involves multi-team collaboration, complex business processes, or many unknown requirements; if yes, and the team is willing to invest half a day to a full day in workshops, it is applicable.

Q: How to handle disputes during a workshop?

A: Use red sticky notes to mark contentious points, set timed discussions (e.g., 15 minutes), and if unresolved, record as pending items for later research and feedback by responsible persons.

Q: How to translate outputs into actual development tasks?

A: Break down event flows into user stories or task cards, define acceptance criteria (e.g., "after event X triggers, system state Y updates"), and include them in the iteration backlog.

Recommended Resources

• Book: "Introducing EventStorming" by Alberto Brandolini, detailing methods and cases.
• Online course: "Event Storming Fundamentals" on Pluralsight, offering hands-on exercises.
• Community: DDD Europe conference talks, sharing industry best practices.

Related Methods

Event Storming is often combined with Domain-Driven Design; other related methods include:

Event Modeling

User Story Mapping, for product requirement梳理; Example Mapping, for refining acceptance scenarios.

Core Quote

"Center on events to make implicit knowledge explicit." — Alberto Brandolini