Focus on the Core with Event Storming and DDD Domain Relationships - 1

4 minute read

Functional Areas are a key aspect of DDD. Here is a DDD and Event Storming activity to find what kind of domain relationships will ensure focus on core areas.

This is the 12th post in a series about how to use Event Storming to kick start architecture on good tracks. It might be a good idea to start reading from the beginning.

Following the previous posts, here is where we stand

  • We have identified functional areas
  • their relationships
  • and where should the decision power be

đź’ˇ Focusing on core domains is the key to long term profitable and sustainable pace

Drawing of a stronghold with a 'CORE' flag in an event storming design board. DDD and Event Storming can be used to draft architecture that will safeguard your core bounded contexts.

Core areas contain our competitive advantage. Focusing on them is the key to long term profitable and sustainable pace. In practice, we want core areas to always keep the priority, the budget, the time… Let’s see how we can use Event Storming and DDD (Domain Driven Design) to make sure that core areas always keep the upper-hand.

DDD Domain Relationship Patterns

Cover of the DDD book by Eric Evans. It contains a lot of relationship patterns to make sure the core functional areas keep the upper hand

DDD can do one more thing for us. In the blue book, Eric Evans lists some domain relationship patterns. These patterns are a bit like a relationship contract between 2 functional areas. They cover technical, human and team organization aspects.

The use of relationship patterns serves 2 purposes:

  1. It will help us to pick the good relationship pattern as we design the system. This in turn makes sure core areas keep the upper-hand and won’t get blocked.
  2. With explicit relationships, everyone will understand better what is expected from them.

Unfortunately, this remains very abstract, and could grant us the astronaut architect badge. Nonetheless, using relationship patterns correctly is a great boost to architecture.

Let’s see how to make this more down to earth.

Walkthrough

This step is going to be critical but also difficult because you don’t want to lose people. A good idea is to start this in the morning, with everyone fresh. You’ll start discussing architecture and system organization. As a result, it’s going to be more technical than the rest of the Big Picture Event Storming. The presence of business people is still very useful because most relationships have organizational consequences. It will be easier to get their buy-in if they remain in the loop.

Photo of an apple. Event Storming is a great at making DDD digestible to everyone

Here is a trick to keep things digestible.

Radars

In his presentation “Context Mapping in Action”, Alberto Brandolini characterized the relationships. Here is a slide from his presentation:

A Slide from presentation 'Context Mapping in Action' by Alberto Brandolini, the inventor of Event Storming, where he defines the 'Big Ball of Mud' DDD domain relationship pattern as Flexibility 1/5, Maintenance 5/5, Skills 1/5 and Organization 1/5.
From Alberto Brandolini’s “Context Mapping in Action” presentation

I built on top of his work and mapped the others as well. (I did my best, feedback is welcome.) Here are the different dimensions and what they mean:

  • Ease of organization
  • Ease of coding (Alberto’s Skills)
  • Ease of maintenance
  • Decoupling (Alberto’s Flexibility)

Sample radar for Big Ball of Mud. These radar allow to present DDD domain relationship patterns in a visual way to Event Storming attendees

I flipped some dimensions so that the wider the radar surface, the better, or simpler the pattern. I also adapted naming to make this more explicit.

We need the attendees to brainstorm the relationships they envision in their system. Unfortunately, these relationships are something new to them. If we dump the 10 relationship patterns at once on them, they won’t understand a word. Before asking them for relationships, we need a way to introduce them in a digestible way.

Here again, we’ll use stories.

Photo of a poster presenting the tales of 2 startups. Storytelling is a powerful way to introduce DDD domain relationship patterns to Event Storming attendees in a digestible way

đź’ˇ DDD can seem too abstract, use Event Storming to present it with storytelling.

Once upon a time, there was a college dropout startup…

We’ll use this made up story to present only the most simple relationships. By simple, I mean (arbitrarily) ease of organization ≥ 2 and ease of coding ≥ 3.

  • Big Ball of mud
  • Separate Ways
  • Conformist
  • Customer Supplier
  • Inner Source
DDD Domain Relationships Radars by Philippe Bourgau

The trick is to present the story as a tale. Next step is to present the relationship and stick the radars on the wall at the same time. Leave a few minutes for everyone to understand what this means.

Make sure everyone understood the kinds of relationships before moving on. It’s then time to ask attendees to pick one for every area relationships. Just stick a post-it with the initials of the pattern on top of the relationship post-it.

The last thing to do is to ask their feedback about the design they came up with. Most likely, they won’t be very happy with it.

Photo of the Event Storming design board after attendees have chosen the DDD Domain relationships in the College Dropout Startup scenario

To be continued

In the next post, I’ll go the veteran startup scenario. I’ll also close this activity with the outcomes, as well as a few animation tricks.

Event Storming is a DDD accelerator. In less than a week, you can get your product started as if it had been going for months. This will save tremendous rework later on. Coupled with refactoring skills, it is key to a profitable and sustainable pace. This was the 12th post in a series about how to use Event Storming to kick start architecture on good tracks.

Continue Reading….

Comments