Why should you run a Design Level Event Storming?
Design Level Event Storming is a workshop to design the core of your system. What is it exactly? What are its outcomes? Where should you use it?
Imagine you are starting a new product with your team. You had been struggling for a while about how to start.
- What should the high-level design be?
- What should we focus on first?
- What are the main risks?
All these questions remained unanswered until you heard about Event Storming!
You decided to try Big Picture Event Storming. As a result, you drafted a functional architecture vision in one or two (intense) days! That’s more progress than you had made in weeks. Also, you managed to identify the functional areas in your domain. Then, you have highlighted the topics you’ll focus on to create your competitive advantage. These are your core bounded contexts.
Everyone on the team now understands where to focus. So, finally, it looks like the teams are ready to start!
💡 Wait, how do you get from the Big Picture Event Storming to designing and writing software?
Event Storming has more to offer! We can zoom in with Design-Level Event Storming. We’ll look into the following questions:
- What problems does Design Level Event Storming solve?
- What are the outcomes of Design Level Event Storming?
- How does Design Level Event Storming work?
- On which parts of your system should you run a Design Level Event Storming?
What problems does Design Level Event Storming solve?
It’s a way to create a collaborative design with a whole software team to solve problems like:
- How can we make good enough design decisions in 1 day instead of months?
- How can we be sure that everybody on the team understands our target design and pulls in that direction?
- How can we leverage the perspective of everyone and not just of a few experts?
What are the outcomes of Design Level Event Storming?
The Design Level flavor of Event Storming lets you dive into the details of a bounded context. Its primary outcome is a good enough and shared design vision. Developers who attend the workshop should be able to start coding straight away.
💡 Big Picture Event Storming was about exploring strategic and large-scale Domain Driven Design; Design-Level Event Storming is about small-scale DDD inside a domain.
During your Design Level Event Storming, you will:
- Detail the information contained in domain events
- Draft what the screens should display
- Identify potential services in your architecture (aka Aggregates in DDD Vocabulary) and what they should do
- Identify the need for interaction with external systems, which is the starting point for API design
- Pinpoint critical issues: the most pressing problems and the primary domain concept definitions.
- Get the whole team to collaborate and design together
- Align all the team towards a shared vision, which saves tremendous time as developers all nudge the code in the same direction!
- Set the team on a sustainable pace by finding the perfect balance between Big Up-Front Design and Emerging Design!
💡 A DDD Aggregate is a small-scale programming pattern that recommends creating and destroying objects as grapes with a root.
How does Design Level Event Storming work?
Similarly to Big Picture Event Storming, the Design Level flavor is a time compressor! It relies on intense and high-bandwidth collaboration. It follows the same dynamic as Big Picture Event Storming, though it’s a bit more detailed and technical.
On which parts of your system should you run a Design Level Event Storming?
Design Level Event Storming is a zoom-in, yet not all system parts require that much attention! Here are three pre-requisites to know on which parts of your system you should run a Design Level Event Storming:
- First, you identified it as business-strategic and a business differentiator.
- It’s a real functional area about which developers and non-developers can talk and understand each other. It’s not a technical brick that only developers can understand
- It contains complicated domain logic that deserves Domain Driven Design (ex: finance. If there are books written on this domain, it’s a clue!)
These checks should look familiar if you ran a Big Picture Event Storming before! This is because they correspond to your core bounded contexts. Design Level Event Storming is a natural continuation of Big Picture Event Storming.
If you haven’t run a Big Picture Event Storming before, as long as the previous checks are ok, Design Level Event Storming will work! You’ll have to start with a quick “mini big picture event storming” on your scope. That’s also a way to “redo” a quick Design Level Event Storming to adjust as you progress.
Finally, Design Level Event Storming is particularly well suited to design microservice or Event-Sourcing systems. If you plan to architect your system with these, that’s yet another incentive to use Design Level Event Storming.
Conclusion
If you have identified a functional area of your system that is:
- A key business differentiator
- It contains complicated domain logic that deserves Domain Driven Design
Then run a Design Level Event Storming with the whole team which will build it! In a few hours:
- You’ll make complex design decisions that would have taken months
- You’ll get a head-start on design
- Everybody will be moving in the same direction
We’ll soon write about how to facilitate your first Design Level Event Storming!
This blog post is part of the 1h Event Storming book that we are currently writing.
A previous edition of this post was originally published on Philippe’s blog
Leave a comment