Ensure core contexts have the upper hand with Event Storming and DDD
Event Storming and DDD can identify bounded contexts. In a bounded contexts relationship, one side will have the upper hand (be upstream). Core contexts should!
The previous post was about how to classify bounded contexts as core, generic or supportive.
For the system to work, bounded contexts must collaborate together. As an example, let’s see what the cart goes through in an e-commerce system. Once the shopping context did it’s work and filled the cart, the ordering context must receive its content. As long as domains need to interact in some way, there is a relationship.
Very often, when 2 contexts have a relationship, one will have the upper hand. Having the upper hand means having more decision power than the other. DDD has the (abstract) concept of upstream and downstream to identify who as the upper hand. Upstream has the power, Downstream complies.
💡 Upstream bounded contexts enjoy more focus, prioritization, quality and investment… at the cost of other contexts.
Obviously, we want our core bounded contexts to be upstream.
This is the 11th 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.
Where does decision power come from?
Many things can weight towards which bounded contexts is upstream or downstream. Unfortunately, not all are good reasons!
- Because it is very old legacy code that is almost impossible to change
- Because it’s an API that is directly used by some customers that don’t want to change it
- Because it is a core bounded context and we constantly make sure it keeps the decision power.
- Suppose the code is the big boss’s own baby, because he wrote it a long time ago. He might always grant more priority to this bounded context! See Alberto Brandolini’s post about the Dungeon Master for more details.
- Suppose there is a big customer who weights 30% of yearly revenues. The features of the systems his business relies on might get more decision power!
Obviously, some of these reasons are good, while others are bad… If your core contexts does not have the power, you are in trouble.
An activity to identify upstream-downstream
To teach this notion, I use this simple activity. Start by quickly introducing the concept. Present the poster, and ask attendees where post-it-X should be. I also ask where it often falls in their current system. It’s often enlightening for people to understand the flaws in their current system. I’ve seen people realize why they suffer so much from their legacy with this activity.
Developers often first misinterpret this with code dependencies. It’s a good idea to clarify that these 2 concepts don’t necessarily map to one-another. For example, your API might not depend on customer code. Unfortunately if your “Top Customer” does not want to migrate to a new version, you’re stuck!
The next step is to ask the group to find relationships between contexts. Every time they spot a relationship, ask them which bounded context should be upstream. It’s usually obvious. We want core contexts to be upstream. Deduce which contexts should be upstream from the core / supportive / generic classification.
Here is how to materialize the relationship. Stick a post-it on the boundary between contexts. Find a way to represent what is upstream or downstream. If contexts are far away, use some wool string and stick the relationship post-it on it.
Outcomes
First of all, this step introduces a new concept to attendees. This notion is very often new and enlightening to participants. It will help them to think of code and organization dependencies in a new way. They should see problem in the current organization. They will also start to have refactoring ideas to put things in a better state.
If you are developer in a team that is downstream, it might be a good idea to try move to another team. Life in downstream environment is often painful.
💡 Moving to an upstream team might be the quickest way to find a more sustainable pace
It can also be a good time to introduce Hexagonal Architecture and its benefits for core areas. Making a core area free from any dependency keeps it more testable and evolutive.
To be continued
This is only a fraction of what DDD offers about smart dependency management. In the next post, we’ll see the patterns of relationships from the DDD blue book. I’ll also walk through an Event Storming follow-up activity to pick the best pattern.
This was the 11th post in a series about how to use Event Storming to kick start architecture on good tracks.
Leave a comment