Event Storming Tech Talk

Slides are taken from

• 50000 Orange Stickies Later by Alberto Brandolini (video)
• Know the Flow by Martin Schimak (video)

What is Event Storming tl;dr

• Fast and low overhead method for collaboratively discovering a business domain and enabling decision making, like
  • Identify core domain: Buy or make?
  • Bottlenecks and pain points? Manual workarounds possible?
  • Context boundaries?
  • Building blocks?
• Individuals and interactions over processes and tools
  • enable conversations
  • empower people
  • create a shared mental model
• (Domain) Event + (Brain) Storming
• Conceived by Alberto Brandolini, still evolving

Motivation

Understanding the problem domain is hard

• "Is the problem they want solved the problem that needs to be solved?"
• Social problem
• "If only we had asked Bob..."
• Scrum doesn't help

Round-robin interviews with all domain experts not ideal

• Rashomon: One crime, four versions of the truth
• Avoid being the detective: let all stakeholders figure out the truth collaboratively

Big Picture Event Storming

Finding the truth collaboratively (what happened?)

Outcome allows decision making

Blockers, bottlenecks, pain points

Context boundaries

Each discarded post-it represents a conversation or an act of learning

Example: Finding context boundaries (Domain "Organizing a meet-up")

Indicators

• cluster on timeline
• triggered by potentially a single command
• ends potentially with a single event
• language different from other clusters
• different stakeholders

Read a summary of the workshop

Other Scopes

Big Picture for complex environments

• low zoom events, birds eye view
• emerging model
• defer consensus
• identify probing opportunities
• "throw away the model"

We need variations for less complex scenarios

Process Modelling

Example: Order process

Policies might also represent context boundaries

An example of process modelling

• 45 minute experiment by Team Turtlez
• three different flows of order fulfillment: FFC 2.0, FFC 1.0, DHL (trivialized)
• understanding of whole process is vague
• maybe an interesting experiment: are policies on the correct zoom level?

Software Design

typically for complicated environments

• Scope is heavily constrained
• Identify patterns, good practices
• Consensus is needed
• maybe keep the model

Example: Change email address

Problem: Customer wants to change her email address in online shop

Disclaimer: Not the original model, just a reconstruction

Scope is constrained :

Pattern: Command, Aggregate (with invariants), Event

Decoupling with policies:

Pattern repeats itself...model emerges

Rethinking aggregates, introducing read models

More read models...

Success - a lot of new discoveries

A model that could almost be implemented

Summary - different formats for different zoom levels

• Scrum Masters - an interesting methodology for your tool-belt that improves refinements
• Product Owners - don't be the detective: let your team and your stakeholders meet regularly
• Developers - take event and policy zoom levels into account when before creating new microservices