ddd

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.