The previous post was about how to classify functional areas as core, generic or supportive.
For the system to work, functional areas must collaborate together. As an example, let’s see what the cart goes through in an e-commerce system. Once the shopping area did it’s work and filled the cart, the ordering area must receive its content. As long as domains need to interact in some way, there is a relationship.
Very often, when 2 areas have a relationship, one will have the upper hand. Having the upper hand means having more decision power than the other.
💡 Upstream bounded contexts enjoy more focus, prioritization, quality and investment… at the cost of other contexts.
Obviously, we want our core functional areas to have the upper hand.
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 in which functional area gets the upper hand. 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 functional area 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 area! 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 area does not have the power, you are in trouble.
Again, DDD has the (abstract) concept of upstream and downstream to identify who as the upper hand. Upstream has the power, Downstream complies.
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 areas. Every time they spot a relationship, ask them which area should have the upper hand. It’s usually obvious. We want core areas to be upstream. Deduce which areas should have the upper hand from the core / supportive / generic classification.
Here is how to materialize the relationship. Stick a post-it on the boundary between areas. Find a way to represent what is upstream or downstream. If areas are far away, use some wool string and stick the relationship post-it on it.
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.