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

Bounded Contexts 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 contexts.

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 bounded contexts
• their relationships
• and where should the decision power be

💡 Focusing on core domains is the key to long term profitable and sustainable pace

Core contexts contain our competitive advantage. Focusing on them is the key to long term profitable and sustainable pace. In practice, we want core bounded contexts 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 contexts always keep the upper-hand.

DDD Domain Relationship Patterns

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 bounded contexts. 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 contexts 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.

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:

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)

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.

💡 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 bounded context 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.

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….

Stay up to date with content and upcoming products

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!