Difference between Event Storming and Event Modelling

The subtleties between big-picture and dependencies

Photo by Parabol | The Agile Meeting Toolbox on Unsplash

Event Storming

If you followed any content about the Strategic side of DDD you no doubt stumbled upon Event Storming. Simply put it’s an exchange of understanding of the underlying domain. Engineers seek to understand how the business side sees and explains what’s going on with processes, data, types of users, roles, constraints, invariants and grouping it together into aggregates and contexts.

This exercise is usually conducted on a Miro board or physical whiteboard, moving notes of various colors to denote a flow of events - an event stream describing cause and effect: the relationships between various state transitions.

The colors are generally:

• Orange: Events. Events are immutable historical facts in past tense (X happened)

• Blue: Commands. These describes human interaction on a UI or triggers from automation

• Red: Disagreements / Language conflicts. These are often a signal of a boundary or border. Think of it like 2 teams using the same word for a similar, but not identical concept. The red hotspots are where they interact.

• Purple: Policies / Invariants describe business rule that have to be true at all times. Policies describe rules for a particular process

• Pink: External Systems. 3rd-party providers, offline processes and/or physical elements go here.

• Yellow: Aggregates. A group of commands that “change together” around a central root. Usually information within an aggregate is heavily correlated and data synchronisation boundaries have to be enforced.

• Green: Read Models / Information. Green items are anything you may need to setup a UI screen, reports or task management for automation.

Event Modelling

Event Modelling is something I haven’t encountered much until last year when I spoke to its inventor Adam Dymitruk on the Technologist Podcast. If you’re completely new to this, I recommend you start there as we explored almost all details over the course of 2 hours.

Visually it looks similar to event storming and uses the same colors and post-it terms with a few distinctions:

• Green: Projections.

• White: UI Screens.

• *Aggregates are now horizontal swimlanes along the timeline, grouping events

• *Vertical Slices group together a single loop of UI→blue → orange → green→UI.

These slices are what make event modelling unique as they allow the mapping of the entire data flow of an application. Slices follow simple rules:

• UI’s and Automation create Commands

• Commands create Events

• Events update Projections

• Projections are used by UI or Automation

You may notice these are looped. This is an intentional property of event modelling.

Use Cases

It is easy to think it is the same as Event Storming, however they are used differently. Event Storming is more like a one-off brainstorming to extract large amounts of Domain-specific jargon and information. They extract complexity that define business concerns.

Event Modelling is more akin to Extreme Programming and Agile. It is used as a tactical planning tool to manage complexity of the delivery process. As the vertical slices are put together, gaps in knowledge and data flow quickly emerge as the system has to be connected entirely left-to-right.

This also exposes easy methods of mocking data, faking static content to reverse-engineer the deployment process and start at the finished state, working backwards.

Summary

Storming Builds Trust Between The Business and Developers

Product Owners come out of my storming sessions relaxed and elated that their developers understand what they are building which builds an important pillar of trust within the business teams.

Modelling Prioritizes Parallel tasks from Highest to Lowest Value (or practical application)

Stakeholders relax when viewing a detailed Event Model because it demystifies the delivery process to them and they can follow-backwards the complexity involved in building something. Usually they are somewhat skittish around no UI changes when effort is backend heavy or having UI changes for a while and then it stops.

Being able to follow the progress of the project through an event model gives them that power of transparency back to manage the delivery and set expectations.