4 tips that will make your DDD Big Picture Event Storming successful
Although not rocket science, running a DDD Big Picture Event Storming can be tricky. Here are 4 hard won tips that will make your first workshop successful.
ℹ️ NOTE: Parts of this post has been republished and updated on the Event Storming Journal blog
This is the 8th post in a series about how to use Event Storming to kick start architecture on good tracks. Previous posts
- explain why Domain Driven Design (DDD) Big Picture Event Storming matters
- walkthrough a workshop in details
If you are not familiar with Event Storming, it might be a good idea to start reading from the beginning.
Here are the most important tips I discovered by running my own workshops.
Tip#1 Manage time with Pomodoro
A double Pomodoro is the most productive and sustainable time schedule. If you are not familiar with the Pomodoro technique, the Wikipedia page is a super short crash course.
💡 A double Pomodoro is the most productive and sustainable time schedule for a DDD Event Storming.
| Characteristic | Classic Pomodoro | Double Pomodoro |
|---|---|---|
| Length | 25 minutes | 50 minutes |
| Short break | 5 minutes | 5 minutes |
| Long break every | 4 pomodoros | 2 pomodoros |
| Long break | 15 minutes | 15 minutes |
When I tried the classic Pomodoro, I was cutting interesting discussions all the time. In practice 50 minutes seem to work better.
People usually overflow the break, so most Pomodoros take a full hour instead of 55 minutes. Without enough breaks, people will get tired and the workshop will not be as productive.
Doing 2 hours before, and then 2 hours after lunch works better than 4 hours straight.
Tip#2 Assign roles for B2B for domain experts
Running an Event Storming workshop is especially challenging for Business to Business vendors. It is very difficult to find real end users or client domain experts to attend the workshop.
A trick is to do some role play, and assign business roles to in-house domain experts. This way, all aspects of the business get dedicated focus during.
💡 If you don’t have real domain experts, assign business roles for DDD Event Storming.
It’s very easy to prepare the roles in advance, with the help of your sponsor.
Tip#3 Don’t try to Event Storm your Legacy
If you are envisioning to refactor your legacy system, do as if you were starting from scratch.
It does not make a lot of sense to Event Storm what you currently have. Legacy systems were rarely designed with DDD in mind. You might have to dive into technical aspects to model them. I once let this happen. The workshop drifted into an unproductive mapping of current technical dependencies.
💡 For legacy refactoring, run DDD Event Storming as if you were starting from scratch.
On the other side though, it can be difficult for developers to “forget” the design of the current system. Especially as they start to see all the refactoring to do. Reassure them that you’ll discuss the transition road later on.
Tip#4 Get the Event Storming Book
My last advice is to buy Alberto Brandolini’s book about Event Storming. The last section contains tons of extra tips and advices.
To be continued
This was the 8th post in a series about how to use Event Storming to kick start architecture on good tracks.
In the next post I will explain how to use DDD Big Picture Event Storming to draft a target architecture.
Leave a comment