Event storming, starting with Domain Driven Design

Event storming, starting with Domain Driven Design

Domain Driven Design(DDD) is not just following another technical template like the many DDD templates that you find on GitHub. If you immediately start working with those templates in code, without exploring your Domain Model first, then chances are high that you are not working towards a Domain Driven Design.
You can't just define classes and group them in a data-driven way and name this group a bounded context, with one or more aggregates, value objects, etc. Changes are that you are now working really hard towards an anemic domain model.

In order to work towards a real Domain Model it is recommended to follow an 8-step process which has been perfectly set by the DDD crew. https://github.com/ddd-crew/ddd-starter-modelling-processDDD crew

Steps to take are:

  • Understand
  • Discover
  • Decompose
  • Strategize
  • Connect
  • Organize
  • Define
  • Code

The phases "Understand" and "Discover" are all about exploring the domain and creating a shared understanding among the entire team. The Understand phase is about understanding the business process itself. Mostly this is done by creating a business process model that the software facilitates.
Discover is the most important part of the DDD process and is about exploring the complete domain based on the business process (see understand) and creating a map of all the features, events, opportunities, bottlenecks, connections, etc. This is where Event Storming comes in handy and is also recommended by the ddd-crew.

Event storming

Event storming is a workshop format which is invented by Alberto Brandolini. You can read his story here. https://ziobrando.blogspot.com/2013/11/introducing-event-storming.html#.VbhQTn-9KK1

Event Storming is used in the Discover phase of DDD. (Domain Driven Development). Its result will visualize the domain into logical functional/strategic groups. It will show the complexity, event flows, bottlenecks, opportunities, and possible issues or "gotchas".

The process of an event-storming workshop

What do you need?
Big pieces of paper, markers, lots of sticky notes (different colors), a room with a big wall

Who is Participating?
This depends on the context of your event storming session and which departments are involved if you look at the business model that you have from the "Understand" part.

Phase 1 events
Everyone in the room will get orange sticky notes and start adding events on a time-lined whiteboard (map). All the participants need to identify, or help to identify, the different events (something meaningful that has happened) that occurs in the system/process and post them on the whiteboard (map). These events must be written in the past. As if you are looking back on what happened. All the events need to be fully mapped out on the whiteboard/map in a timeline sequence.

Examples of events are:
- The car battery is fully charged
- The subscription has been updated
- etc.

Phase 2 commands
Once everybody is done with posting events, everybody starts posting commands (blue sticky notes). Commands are inputs that result in an event. These commands are placed right before the Events. The commands need to be written in the present. If there is an actor that triggers the command, a small sticky note is placed on the command. The commander can be a system, job, user, etc.

Example of commands (using the previous events)
- Charge the car --> The car battery is fully charged
- Update subscription details --> The subscription has been updated
- etc.

A few more sticky notes
After the commands, you need the participants to keep putting sticky notes on the whiteboard for the following groups:
- Green sticky notes are actions on physical objects.
- Pink sticky notes are external systems or third-party services.
- Purple sticky notes are policies/business logic and describe the "who, when, and where". Examples are business rules, validation rules, security, or any other rule that controls behavior.
- Red sticky notes are for leftovers, concerns, issues, questions, etc.

The workshop result

We have looked at the phases "Understand" and "Discover" (DDD crew). Let's head over to the next phase called "Decompse".

After the tsunami of stick notes, you can already see some similarities and maybe you can already spot some great aggregates.
Try to categorize the "Events" by grouping them in a way in which all events have something in common. For example, take a look at this process. (time-lined from left to right)

What would be logical is to categorize them like so. I added big Yellow sticky notes that categorize the Events. (I also added the green physical objects)

If you look closely at the boundary between "garbage collection" and "garbage disposal" you can already spot a small mistake. Or at the very least have a discussion. About moving the boundary of the garbage disposal. See below


Is "dumping the trash" part of the garbage collection or is it part of garbage disposal? Now this might be worth discussing. :-) Here you also come to the phase of "Strategize". But that is out of the scope of this topic about Event Storming.

The purpose of Event Storming

  • The team gets an idea and overview of the complete domain.
  • The team knows what kind of terminology is going to be used (ubiquitous language).
  • The team will see a logical flow of events and easily identify bottlenecks, inconsistencies, and areas for improvement.
  • It's fun and increases collaboration and communication.
  • It takes hours instead of weeks to get a quite comprehensive domain model.


source: https://medium.com/capital-one-tech/event-storming-decomposing-the-monolith-to-kick-start-your-microservice-architecture-acb8695a6e61
GitHub - wwerner/event-storming-cheatsheet: Short cheat sheet for preparing and facilitating event storming workshops
Short cheat sheet for preparing and facilitating event storming workshops - GitHub - wwerner/event-storming-cheatsheet: Short cheat sheet for preparing and facilitating event storming workshops


GitHub - ddd-crew/ddd-starter-modelling-process: If you’re new to DDD and not sure where to start, this process will guide you step-by-step
If you're new to DDD and not sure where to start, this process will guide you step-by-step - GitHub - ddd-crew/ddd-starter-modelling-process: If you're new to DDD and not sure where to star…
Decomposing the Monolith with Event Storming
Kick-Start Your Microservices Architecture
bliki: AnemicDomainModel
If you use an object-oriented domain model, and you don’t put behavior in your objects, you’re missing out on most of the benefits of that pattern.
bliki: DDD_Aggregate
A pattern from Domain-Driven Design describing a cluster of domain objects that can be treated as a single unit for persistant storage and transactions.
How To Run Your First Event Storming Session
If you wonder how to run your first successful Event Storming session, this article will give you all the relevant info on how to properly set everything up.
Event Storming Workshop: A Game-Changer for Mapping Complex Business Domains - nexocode
Aligning teams with business domain knowledge is a crucial part of software development, and Event Storming workshops provide an opportunity to gain a deeper understanding of the business processes, map user flows, and unlock opportunities for optimization.
Demystifying Event Storming and Aggregates
You might have heard about Event Storming, a fantastic technique for collaboratively modeling complex business domains in a fun, engaging, and interactive way. You bring together people from different backgrounds to brainstorm and visualize the inner workings of a business domain.
Domain-Driven Design vs. anemic model. How do they differ?
Some time ago during one of our internal DDD learning group meeting I was wondering what is the best way to show differences between writing an application with an anemic model and application with…
Model Event Storming Results in Context Mapper
Event storming is a workshop technique to explore domains originally invented by Alberto Brandolini. If you are not familiar with the technique we recommend the following literature and links: