Featured image from 3dots

Event storming by Alberto Brandolini is a great way to gather information and understanding about a domain.

What is it?

It is a workshop based method to find out what is happening in the domain of a software program. It is extremely lightweight and intentionally requires no support by a computer. The business process is stormed out as a series of domain events which are denoted as orange stickies and other elements on stickies of different colours on a wall. The idea is to bring domain experts and software experts into a room and discuss how the business works in terms of events that are important to the business, thereby helping the both the software team and the domain team to learn from each other.

What does event storming solve?

  • Provides visibility and eliminate assumptions
    • Visualise what happens when and what-if scenarios
    • Uncover hidden behaviour
  • A modelling language that everyone understands - tech and business alike
  • Involves many people simultaneous unlike traditional meetings
    • Small groups of people discussing particular areas and uncovering details at that level
  • Allows expressing terms, behaviour, model processing and decisions.
    • Not a feature or data

Behaviour is the central aspect of domain knowledge and Event storming focuses exactly on this - how does the business work.

Types of Event Storming

  • Big Picture Event Storming
    • Get an understanding of how the business works
  • Design Level Event Storming
    • Get an idea of implementation complexities
    • Focusses on a particular bounded context

Both types of session, involve two groups of people, those asking questions and those answering or clarifying them. Unlike traditional meetings, event storming requires, people to form groups and storm on areas of the domain.

Key Concepts

Domain Events

In a business certain things happen - facts of life - that lead to some change in state of the system and might trigger other behaviour. These are Domain Events. This is why it is called Event Storming. Domain Events are something that really happened - not something that someone wanted.

Hotspots

When discussions during the session get heated and hinders progress in exploring other areas, we have identified a Hotspot. An area that needs a separate detailed discussion to uncover additional information.

External Systems

Most businesses interact with systems or organisations that are not within your domain. These are external systems and must also be represented on the board during workshops.

Big Picture event storming workshops

For a good workshop, you will need two types of people:

  • The ones with questions or the ones trying to understand the problem to build a solution
    • Business Analysts/Product owners
    • Software engineers - Dev & QA
  • The ones with answers, the ones who know the problem domain well enough to answer potential questions. AKA Domain Experts. They do not know everything but often have an illusion of knowledge.
    • Quite often require more than one as each one might have an area of expertise
    • Must know how things are done and how it should be done

Preparation for the workshop

Both groups must prepare for the workshop:

  • Formulate good questions
  • Think about the problem, issues, and current assumptions
  • Business must know or be aware of their needs

Questions and the curiosity and willingness to understand the domain is what makes a successful event storming workshop

Preparing the space for a physical workshop

  • Large room - large enough to occupy the people and allow them to freely move around
    • Might have to move chairs and desks out
  • Stationary
    • Plenty of post-it notes of different colours - particularly orange
    • Lots of sharpies or permanent ink markers for writing into the stickies. Ensure that they all work. This is crucial. You don’t want to waste the time of the people you have invited by giving them stationary that doesn’t work.
    • Large roll of paper and blue-tac to stick on the wall (to avoid damaging/accidentally writing on the wall instead) and cover as much space as you possibly can on the wall to get more of the domain modelled.

Preparing the space for a virtual workshop

  • A real-time collaboration tool like Miro

Timing and scheduling

  • At least 2 hours for a session
  • Any longer and ensure plenty of breaks are included
  • Provide plenty of refreshments - fruits, sweets, coffee to avoid energy levels from dropping

The workshop in progress

Kickstart the session

  • As a facilitator, explain the rules and hand over the stationary or direct participants to it
  • Create a legend for reference:
    • What colour sticky represents what?
    • How to write domain events, actors, policies, etc
  • Encourage participants to begin, if no one starts, put the first post it on the board
    • Alberto recommends:
      • Put anything on the wall, something silly or something serious
      • Either way will start a discussion
      • Better not be the beginning of the timeline
    • Another recommendation by Dan North (DDD eXchange 2016 | 9th - 10th Jun 2016 | London (skillsmatter.com)):
      • Once upon a time on the left most part of the board
      • Happily ever after on the right most end
      • Events come in between
      • This gives people a sense of time and start with something

Role of a facilitator

  • Facilitator is to observe and guide - not restrict
  • Fewer rules imposed, the better the workshop
  • Facilitator to interfere in heated discussions to mark the area as a hotspot and move on
    • Hotspots are areas that need further discussion
    • Usually marked in bright pink by convention
    • Hotspots help plan further sessions
  • People tend to ask the facilitator questions
    • Facilitators must direct the questions to the right people
    • Unless the questions are about what stickies go where
  • Ensure that everyone understands that Domain events are not technical
    • Just things that happen during the business
  • Ensure that people do not put feature requests on the board
    • Remind them that event storming is to understand the domain as it is today

The crucial thing is:

  • Everyone has to participate.
  • Developers have to ask questions too
  • Facilitators must probe the developers if they are too quiet
  • There might be a way that the business deals with what developers would normally consider “an exception” in code. Ensure that this is discussed

Identifying Contexts and Context Maps

  • When there are many domain experts, some of them might group together and get into discussions on a specific functional area.
    • This might be your contexts within the domain
    • Connecting these separate contexts could build your context map
    • As a facilitator, do not discourage this
  • Businesses often work with external companies or other systems. Note them as external systems and put them on the model
    • Domain events could lead to these systems
    • Domain events could come from these systems too
    • Alberto’s recommendation -
      • Large Pastel pink sticky notes
        • Payment provider

Post workshop

  • Keep track of hotspots
    • Might have to schedule discussion with smaller group of people
  • The roll of paper may not be used again, as it might have already delivered its value by flushing out the understanding about the domain. No harm in keeping the paper but rarely looked at later.
  • Take pictures of the areas on the roll,
  • Often, it might be more productive to start from scratch again later, but keep the roll for weeks or months.

Design Level Event Storming

Preparation

Pretty much the same as Big Picture Event Storming. Except, the people, who will be involved.

In this session, the participants are limited to but must include:

  • Those developing the solution - developers/qa
  • The one responsible for the system - product owner/manager
  • Domain expert

Limiting the scope and number of people, helps delve into a much higher level of detail into the design.

Additional Concepts

As this session involves not just domain events, but lower level design, we will have to represent many other types of domain concepts on the board. However, yet again, we must try to only visualise programming language agnostic concepts.

Commands

That which expresses a user’s intent. They produce a state transition, that results in events being emitted inside our domain model. Alberto recommends, Blue sticky notes for commands.

  • Example: Activate Deep Scanning command, would eventually result in Deep Scanning Activated
  • Similarly, avoid arrows. Flow is generally from left to right. Arrows result in spatial locking -> not on miro at least.

Queries

This represents what a user wants to see, in order to take decisions to execute command(s)

Read models

What users look at before asking the system to do something.

  • Application screen, mobile app, web app, dashboard, form, etc.
  • Comprises of elements of a limited set of types:
    • Text and images - displayed information - depends on readmodel
    • Input boxes, checkboxes, radio buttons - form elements - depends on readmodel
    • Action buttons - sends commands
    • Navigation - move from one screen to another
    • UserReadModel
      • Name, surname, job title, phone number, country, email address

Users

Those who queries and views the read models, who sends commands, who can do what?

  • Different roles
    • Users are visualized with smaller sticky notes with an stick figure and a name written underneath - to show what type of user

Policies

When a user sends commands to the system, it triggers a state transition, and publishes events which trigger other parts of the system to issue commands to further cascade related changes. Work of a command must be to the absolute minimum. Policies subscribe to domain events and when a policy receives a domain event it is interested in, it will check the event content and potentially send another command to complement the work. This sort of a behaviour is called reactive behaviour and systems that actively use the pattern can be referred to as reactive systems.

Summary

The picture that explains almost everything - Alberto Brandolini