Defining the Domain

Using Event Storming

Barry S. Stahl

Solution Architect & Developer

Transparent Half Width Image.png

Favorite Physicists & Mathematicians

Favorite Physicists

  1. Harold "Hal" Stahl
  2. Carl Sagan
  3. Richard Feynman
  4. Marie Curie
  5. Nikola Tesla
  6. Albert Einstein
  7. Neil Degrasse Tyson
  8. Niels Bohr
  9. Galileo Galilei
  10. Michael Faraday

Other notables: Stephen Hawking, Edwin Hubble

Favorite Mathematicians

  1. Ada Lovelace
  2. Alan Turing
  3. Johannes Kepler
  4. Rene Descartes
  5. Isaac Newton
  6. Leonardo Fibonacci
  7. George Boole
  8. Blaise Pascal
  9. Johann Gauss
  10. Grace Hopper

Other notables: Daphne Koller, Benoit Mandelbrot

Some OSS Projects I Run

  1. Liquid Victor : Media tracking and aggregation [used to assemble this presentation]
  2. Prehensile Pony-Tail : A static site generator built in c#
  3. TestHelperExtensions : A set of extension methods helpful when building unit tests
  4. Conference Scheduler : A conference schedule optimizer
  5. IntentBot - A microservices framework for creating conversational bots on top of Bot Framework
  6. LiquidNun : Library of abstractions and implementations for loosely-coupled applications
  7. Toastmasters Agenda : A c# library and website for generating agenda's for Toastmasters meetings


Event Storming

Storm 1024x683.jpg

A process for modeling a business domain from the perspective of the business experts

Why Event Storming?

  • We Learn Things
    • Improved Understanding of the Problem
    • Better Naming of Objects and Operations
    • Separation of similar but different concepts
  • Not Big Design Up-Front
    • Good Understanding Up-Front

Modeling the Domain

  • As the Business Sees It
  • Implementation Agnostic
  • Not storage-centric

Event Storming Output

Final Domain Model - Ask the Sloth.png
  1. Visual Model of the Domain
  2. Ubiquitous Language Document (Dictionary)
  3. Common Understanding Among Team Members

Domain Driven Design (DDD)

Practices for designing systems from components that are highly cohesive but loosely coupled


A measurement of the strength of the relationships within a component

  • Operations
  • Data

How closely the data and the operations on that data match within the context of the component


A measurement of the strength of the relationships between components

  • Operations
  • Data

The greater the coupling between components, the more likely we are to have to change one as a result of a change to the other

Application TCO

  • The Total Cost of Ownership of an application is the sum of all the costs of the application throughout its life-cycle.

  • These costs include creating, deploying, extending, maintaining and decommissioning the application.

TCO Breakdown.png

Loose Coupling Reduces TCO

  • Tight coupling makes it more difficult to modify one concern of the application without impacting others.

  • Maintenance & Extension : more difficult == more expensive

Loose vs Tight Coupling.png

Domain Object

A representation of a real-world entity in software

  • Meaningful to the business users
  • Encapsulates both state and behavior

Bounded Context

A singular viewpoint on the facts and circumstances surrounding a Domain Object

  • Flight
    • Traveler's perspecive
      • Departure & Arrival Times & Locations
      • Class of Service & Seat
      • Loyalty Miles
    • Gate Agent's perspective
      • Number of passengers
      • Boarding Time
      • Crew Members

Ubiquitous Language

Ubiquitous Language - AgileAZ.png

Aggregate (n)

User Aggregate.png

A cluster of domain objects that can be treated as a single unit

Domain Events

Domain Event - Vehicle Added to Inventory.png
  • A fact of significance to the business
  • Described in the past tense
  • Immutable (can't change history)
  • Implementation Agnostic
  • Domain Event ≠ Message

Some Domain Events

  • Item Added to Inventory
  • Flight Scheduled
  • Video Uploaded
  • User Logged-In

The 4 Steps in Event Storming

  1. Collect Domain Events
  2. Refine Domain Events
  3. Track Causes (Use-Case Modeling)
  4. Aggregation (Sub-System Modeling)

Our Problem Domain - Q&A

Question Aanswered 300px.jpg

The Q&A Domain

  • Access from Behind the Corporate Firewall only

    • Using the Company SSO solution only
  • Users Can:

    • Search for Questions and Answers
    • View details of a Question and its Answers
    • Ask a Question
    • Answer an existing Question
    • Comment on existing questions and answers
    • Report an existing Question, Answer or Comment
  • Activity can impact reputation

  StackOverflow Search Results Screenshot - Highlighted.png
  StackOverflow Question Screenshot.png

The Q&A Domain

  • Access from Behind the Corporate Firewall only

    • Using the Company SSO solution only
  • Users Can:

    • Search for Questions and Answers
    • View details of a Question and its Answers
    • Ask a Question
    • Answer an existing Question
    • Comment on existing questions and answers
    • Report an existing Question, Answer or Comment
  • Activity can impact reputation

Step 1 - Collect Domain Events

Domain Event and Question Stickies - 400x400.png
  • Brainstorm Domain Events

    • Use orange stickies for each one
    • Conversations around events are encouraged
  • Identify questions or concerns

    • Use pink stickies liberally

"Infinite" Design Surface

Infinite Design Surface 800x600.jpg

Events Collected

  • Notable Events

    • User Logged-in
    • Question Asked
    • Question Answered
    • Answer Upvoted
    • Comment Submitted
  • Interesting Issues

    • Can a question be edited?
    • Can a comment be upvoted?
    • What happens with duplicates?
    • What is actually searched for?
  Event Storming - AgileAZ - Step 1 - Sample.png

Step 2 - Refine Events

Event Storming Example - After Step 2.png
  • Revisit each event as a team
    • Grow shared understanding for each

    • Add any additional Events that are discovered

    • Resolve pink stickies if possible

    • Leave pink stickies that are unresolved

    • Add new pink stickies for additional questions

Events Refined

  • Notable Changes

    • Events roughly ordered
    • Added Question Removed event
    • Added Report Completed event
    • Filled-In Ubiquitous Language document
  • Issues Resolved

    • Questions can not be edited -- comment instead
    • No upvotes of comments or questions (perhaps future)
    • Searches are for keywords and phrases
  Event Storming - Q&A Domain Sample - Step 2 - Refine Events - 2231x1200.png

Step 3 - Track Causes

Additional Stickies - Wide.png
  • User or Actor

    • A human interacting with the system
    • May utilize View Models
    • May issue Commands
  • Business Process

    • Logic internal to our systems
    • May utilize Read Models
    • May trigger other Events
  • External Systems

    • Logic from outside our organization
    • May utilize View Models
    • May trigger Business Processes

After Tracking Causes

Event Storming Example - After Step 3 - 600x480.png
  • Identify Sources
    • Actor
    • Business Process
    • External System
  • Identify Interactions
    • Which Users trigger Commands?
    • Which elements trigger Business Processes?
    • Which elements utilize Read Models?
    • Which Business Processes create new Events?

Causes Tracked

  • Notable Flows
    • User log-in
    • Search
    • View Question
    • Ask Question
    • Answer Question
    • Submit Comment
    • Submit Answer
    • Upvote Answer
    • Report Question
    • Remove Question
    • Close Report
  Event Storming - Q&A Domain Sample - Step 3 - Track Causes - 2231x1200.png

Step 4 - Aggregate (v)

Event Storming Example - After Step 4.png
  • Group the modeled objects by their Aggregate Root
    • Identify the key subsystems in the model
      • Subsystem is often a good proxy for μservice
    • Err on the side of greater separation
      • It is easier to combine than separate later

Aggregates Aggregated

  • Notable Aggregates
    • User
    • Report (moderation)
    • Search
    • Comment
    • Question
  Event Storming - Q&A Domain Sample - Step 4 - Aggregate - 2231x1200.png



Block the Time Up-Front

  • Size and complexity of the domain
  • Number and the assertiveness of participants

Start In-Person then Go Virtual

  • Step 1 = many conversations
  • Steps 2-4 = 1 conversation

You'll need to be able to transfer the physical surface to a virtual whiteboard

Have a Facilitator

  • The loudest voices should be from the business
  • Technical voices should not be authoritative

Don't Fall in Love with the Model

  • It will hopefully be improved on
  • It will almost certainly change

Update the Ubiquitous Language Often

  • Facilitators - call attention to the UL often
  • Use a spreadsheet for sortability

Drawing Semantics are Not Critical

  • There is no "right way" to draw these pictures
  • Understanding is the important thing

Summary of Recommendations

  • Block the time up-front
  • Start in-person, then go virtual
  • Have a facilitator
  • Don't Fall in Love with the Model
  • Update the Ubiquitous Language often
  • Drawing semantics are not critical


  • Modeling process from the perspective of the business experts
    1. Collect Events
    2. Refine Events
    3. Track Causes
    4. Aggregation (Sub-System Modeling)
  • Powered by Domain Events
    • Triggered by Users, Business Processes and External Systems
    • Supported by Commands and Read Models
  • Produces
    • Visual Model of the Domain
    • Ubiquitous Language
    • Shared Understanding