Transitioning to DDD Through Event Storming: A Practical Workshop Guide from Domain Events to Aggregates

The Essence and Preparation of Event Storming

Event Storming is a workshop-style methodology for a group to collectively grasp an uncertain subject; it is not a tool exclusive to DDD or developers, but a useful tool for identifying and solving problems. To correctly understand a problem, an attitude of acknowledging, as in Feynman's quote, 'what you understand, what you've newly learned, and what you don't understand' must come first.

When conducting the workshop, it is ideal for all stakeholders—domain experts, planners, developers, designers, etc.—to gather in one place, and if there are physical limitations, using Miro is recommended. For detailed processes, you can refer to KAIST's K-MOOC lecture and an IBM developer post.

Key Elements and Placement Rules

The process proceeds in order from domain events to aggregate identification, and each element is expressed with the following colors and rules.

• Domain Events (orange): Events triggered within a business process, expressed using past-tense verbs and arranged from left to right according to the flow of time.
• Commands (blue): Commands executed by an actor to trigger an event, placed to the left of the domain event.
• Aggregates (yellow): A concept encompassing command execution and event occurrence, similar to a real-world document, placed above the commands and events to visually contain them.
• Actors (small yellow): User roles that can trigger a command, displayed small next to the command.
• Views (green): Screens through which users interact with the system, placed to the left of commands to aid conceptual understanding.
• Business Processes (purple): Complex procedures that trigger at least one domain event and unfold independently.
• External Systems (hot pink): Third-party services such as PG (payment gateway) integrations, which either accept events or trigger actions.
• Issues (red): Immediately marked for ambiguous matters or points requiring decisions.

Participation Attitude and Overcoming Difficulties

Event Storming is brainstorming plus tools and rules; since the design is not completed in one go, participants should not fear the process of attaching and detaching. Just as with DDD's concept of Continuous Integration, change must be accepted as part of the process, and as illustrated by Michelangelo's Sistine Chapel sketches, the emphasis is on the process of partial revision leading to completion.

In actual practice, the biggest problem is a 'lack of active participation' due to burden or doubt. Difficulties can arise from the dogmatism or face-saving concerns of participants with domain knowledge, or from an existing business's reliance on improvisation. Vague expressions like 'this, that, the other thing' appearing, or a subject wavering back and forth across a boundary, are evidence that the domain boundary is unclear.

Event Storming requires intuitively figuring out unsystematized areas and concretizing them through active discussion. This is the 'first step' among the countless means for practicing DDD, and persistent curiosity about domain terms and scope becomes an excellent building block for system composition.