How to use Event Storming to introduce Domain Driven Design
Although incredibly effective, DDD is overlooked by developers because of its abstractness. Event Storming is a great way to introduce DDD without naming it!
State of DDD
I first read about Domain Driven Design about 15 years ago. It’s after reading the blue book that I decided to move to the rich domain of Corporate Finance… for the better and the worse!
I still remember the first project where we tried to follow the DDD principles. We were working in a bank, and writing a connector to an electronic broker. For 2 days following the deployment of the first version of our system, we heard nothing about it. This was quite unusual. The broker finally called us to say there was a bug in the way we were handling one message. We did not open the debugger. We only checked our logs. This was enough to explain which business rules where used, and that we thought we were right. 2 more days later, they admitted the bug was on their side.
Granted, this success might also have resulted from all our other eXtreme Programming practices. Still, putting the business logic before technology proved both very effective and sustainable.
15 years later, we’re only starting to hear a bit more about DDD. With the microservices trend, people are wondering “What boundaries should our services have?” DDD’s Context Map is one of the few serious answers available.
Why isn’t an effective concept like DDD more widely adopted?
The barriers to DDD
There are many reasons why DDD is not ubiquitous 😉. First of all, the complexity it brings is not justified for every project. Second, it explicitly builds on top of XP. It almost states merciless refactoring, unit testing and ‘whole team’ as pre-requisites. XP’s adoption is already small, which does not help DDD’s adoption either!
💡 Its awkward vocabulary is one of the reasons why DDD is not more widely adapted.
There’s a third reason why DDD still does not have the place it deserves: its awkward vocabulary! Here are a few examples:
- Ubiquitous language
- Bounded contexts
- Upstream / Downstream
- Aggregates
- Relationships patterns (Shared Kernel, Conformist, Open Host API, Published Language …)
- Hexagonal architecture (Even if not directly DDD)
- …
All these contribute to make DDD look very abstract, and not practical. This is where Event Storming can help. Let’s see how.
Event Storming in a nutshell
Event Storming is a collaborative design workshop. Using a big wall and post-its, a group of people can draft a software system design in a few hours.
Alberto Brandolini invented it as a way to design Event Sourced systems. The workshop itself is pretty intuitive. The rules are straightforward and rely on natural human metaphors. After 1 hour in, people feel at home with Event Storming.
If you want to learn more about Event Storming, check my series of post on the topic.
How to use Event Storming to get people to do DDD without knowing?
Alberto was an early member of the DDD community. Event Storming has huge bias towards analyzing the system from the point of view of the domain. During the Event Storming workshop, many DDD concepts will emerge. For example: Business Events, Bounded Contexts, Actors, Aggregates…
This natural emergence of concepts is a great opportunity to explain to people what they are. Here are a few Event Storming tricks I use to make DDD more accessible.
Functional Area
Although nobody understands Bounded Context from the start, everyone gets ‘Functional Area’. Granted, Bounded Context is a more precise name. It’s also a lot easier to forget it and only mention ‘Functional Areas’ during the Event Storming. People will understand it straightaway.
💡 Talk about Functional Area instead of Bounded Context.
Vocabulary
Ubiquitous Language is a great name… once you get it! It’s easier not to scare everyone out by using ‘shared vocabulary’ instead.
💡 Talk about Shared Vocabulary instead of Ubiquitous Language.
Having the upper hand
The blue book introduces the notion of upstream/downstream relationship between bounded contexts. This concept is very valuable in practice. Unfortunately, it’s not so easy to explain during a workshop. The best introduction I found is “Who has the upper hand in the relationship?”
I also use a special activity to explain it further. I ask people to place a few typical situations upstream or downstream. If you want more details, I wrote a whole post about this activity.
Relationship patterns
The blue book also contains a full pattern language about bounded context relationships. This is of tremendous value to build a conscious functional architecture. Unfortunately, this part of the book is also pretty abstract and difficult to read.
Hopefully for us, Event Storming can help here too. After a while in the workshop, the system should feel more concrete. That allows to introduce the patterns in a less abstract way.
💡 Use radars and storytelling to introduce Bounded Context relationship patterns.
I use a special activity for that. It relies on storytelling and visual radars to compare the patterns. With this, I have had success to introduce the patterns smoothly to attendees.
Blank Aggregates
Aggregate is another concept introduced in the blue book that is not easy to grasp. Explanations involving invariant and consistency don’t make it easier to understand.
Alberto Brandolini himself suggests using a technique he calls ‘Blank aggregates’. At the design level phase, don’t ask people to come up with Aggregates. Instead, put empty post-its and ask people to write business rules. Don’t mention aggregates yet.
Only later ask them to group the business rules ‘as-they-would-with-code’. Developers usually get this well. They’ll naturally find good names for these Aggregates (of business rules).
Start now!
Don’t be a Smug DDD Weenie. You’ll have difficulties to persuade people to jump into DDD. It’s a lot easier to setup a workshop, and get started. For your next feature, product or refactoring effort, start with Event Storming!
For more details about how to run an Event Storming workshop, here is a full walkthrough.
Leave a comment