4 tips that will make your DDD Big Picture Event Storming successful

2 minute read

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.

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.

Sketchnote of the 4 tips to make DDD Big Picture Event Storming Successful. #1 Double Pomodoro. #2 Role Play. #3 Ignore Legacy. #4 Read Alberto's Book

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.

A kitchen pomodoro timer. The double pomodoro technique is great for managing time during a DDD Event Storming
From Flickr By Marco Verch, under Attribution 2.0 Generic (CC BY 2.0) License

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.

Photo of a street actor. Role playing is a great way to make up for missing domain experts in DDD Event Storming

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.

Photo of legacy factory machines. Keeping a legacy system in mind while doing a DDD Event Storming will drift the discussion towards the intricacies of existing systems.

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.

Cover of Alberto Brandolini's book about Event Storming.

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.

Continue Reading….

Comments