Domain-driven design Event storming
In April I had the chance to lead a domain-driven design and event storming workshop for an insurance company based in London. It was an enjoyable two days spent exploring and modelling an insurance subdomain. I arrived with plenty of brightly coloured sticky notes, ready to facilitate an event storming session which included both developers and domain experts.
Domain-driven design introduction
As part of the introduction to domain-driven design I gave the following presentation as an overview of the subject. The slides only cover the subject matter at a very high-level, compared with the in-person talk where I described the concepts in detail.
During the last few months I’ve facilitated event storming sessions for companies based in the UK, New York, and Portugal. In my experience, event storming provides a valuable approach to learn and discover a problem domain while modelling with domain events. It’s a remarkable way of being introduced to a new business problem in a relatively short time period, measured in hours rather than days or weeks spent reading documentation or business requirements.
To help introduce the purpose of all the different brightly coloured sticky notes I use the following legend (click for a full-size image).
After facilitating and being involved with a good number of event storming sessions my advice would be:
- Ensure you have at least six different coloured stick notes (as shown above).
- Prepare the room or area with as much wall space as possible, and no chairs or tables nearby.
- Get everyone up on their feet – easier when there are no chairs around – and huddled around the wall.
- Encourage everyone to participate – don’t allow a single person to dominate.
- Use a purple/pink sticky note to jot down any difficulties you encounter (questions, unclear requirements). This helps to defer unnecessary decisions and prevent getting too far into the weeds, ignoring the bigger picture.
- Limit sessions to 45-50 minutes in duration with a 10-15 minute break in between.
- Start with just the domain events (orange stickies) in a time-based flow from left to right. Once you’ve uncovered all the domain events, start to enrich the model with commands, actors, external systems, and policies. Finally add any aggregates and read models (if required).
Want to learn more?
Please get in touch if your company is interested in learning about domain-driven design or would like me to facilitate an event storming session.