Event Storming

Flexible workshop format for collaborative exploration of complex business domains

Event Storming provides a shared language that bridges the gap between business experts and technical teams.

Event Storming

It was created by Alberto Brandolini, and is described in his book Introducing EventStorming.

Event Storming is a collaborative workshop technique used to explore complex business domains.

Its primary goal is to create a shared understanding among stakeholders, including business experts and technical teams.

It helps to make complex processes more tangible.

Events represent significant occurrences in the domain that trigger changes or reactions.

Commands and Policies are also used to represent actions and rules within the domain.

Design Level Event Storming helps in identifying Aggregates and Entities within the domain. Aggregates are clusters of related objects that are treated as a single unit.

ZDL ~ A Domain Modeling Language for DDD and Event Storming

ZenWave Domain Language (ZDL) is a Domain Specific Language that maps Event Storming discoveries with DDD principles in mind into a developer friendly format.

It works as an Ubiquitous Language, retaining the language of the domain and because is machine friendly it propagates automatically to documentation, code and tests.

Jump to Bounded Context Canvas for details about how to map Event-Storming concepts into ZDL format.

From Vision To Detail

(Source: https://es.slideshare.net/ziobrando/50000-orange-stickies-later)

Big Picture EventStorming

Big Picture EventStorming is ideal for Analysis of a whole Business Domain or Subdomain. Beyond silos, it requires the participation of business experts

(Source: https://medium.com/@springdo/a-facilitators-recipe-for-event-storming-941dcb38db0d)

Design Level EventStorming for Designing Event-Driven Systems for a Bonded Context

Design Level EventStorming is ideal for Designing Event-Driven Systems for a given Bonded Context and while it can be performed by the development team alone, it is recommended to request feedback and validation from domain experts.

(Source: https://mrpicky.dev/design-level-event-storming-with-examples/)

Event Storming Elements

Events

Events play a central role in Event Storming. They represent significant occurrences in the domain that trigger changes or reactions.

Commands and Policies

Commands and Policies are used to represent actions and rules within the domain.

User Initiated Command Produces Event

Commands can be initiated by users.

Policy Initiated Command

Commands can also be initiated by policies. Rules triggering in the background, spanning for other systems events, temporal triggers, external systems, etc.

Command invoked on System produces Event

Commands do not directly triggers events, but they are invoked on a system, which in turn produces events.

Command invoked on Aggregate produces Event

DDD systems are comprised of Aggregates, which are clusters of related objects that are treated as a single unit. Commands are invoked on Aggregates, which in turn produces events.

Read Models in Commands and Events

Read Models represents Value Objects associated to Commands and Events.

Event Storming Steps

Establish the Timeline

First step is discover all relevant events that happened in the domain and sort them in a timeline from left to right.

Find pivotal events: those events where the flow splits into different paths or joins back together. These pivotal events would be good candidates for Context boundaries.

Join events with commands and policies

Next join events (facts) with commands and policies (actions and rules).

Identify Aggregates

Identify Aggregates and Entities within the domain. Alternatively you can just identify Systems and leave Aggreate discovery for a posterior technical design phase.

Split into Bounded Contexts

A Bounded Context is a self-contained entity with its own domain model and its own Ubiquitous Language that is not affected by the outside world.

They help in organizing the domain into manageable parts and in defining the interactions between different parts of the system.

Describe the Bounded Contexts using Bounded Context Canvas and ZDL Model Language

Use a Bounded Context Canvas to describe the inputs, outputs, aggregates and policies of Bounded Context.

You can describe the Bounded Context directly using the developer friendly and machine friendly ZDL Model Language.