Domain-Driven Design: scaling beyond one team

The way we look at the world influences what we perceive. A different perspective often allows us to discover new details. Looking at something in just the right way can lead to powerful insights.

Domain-Driven Design can teach us to look at our organizations in a new way. It places an emphasis on human interactions instead of technical details. It draws attention to the prevalent communication structures. In doing so, it reveals the hidden forces that shape our software systems.

Let’s recall Conway’s law. It states that organizations design systems which mirror their communication structures. This is because two pieces of software can only interact with each other when their designers have communicated before.

But although we know how much influence our communication structures have on the systems we design, we rarely apply that knowledge.

Let’s take a look at one of the most common techniques used to represent the structure of an organization: an organigram.

An organigram brings out one kind of relationship: who reports to whom. In doing so it accentuates the relative rank of each employee. Interestingly enough, people often make a big thing of this kind of structure. I suppose, this is because someone higher up the tree oftentimes wields more decision power than those below them.

However, this is not what we need to be looking at in order to understand the forces that shape our software. Conway’s law advises us to look for the communication paths. But those don’t even appear in an organigram.

What we need is a diagram that captures the prevailing communication paths. Luckily, Domain-Driven Design has just the right tool for us.

Coping with information overload

Think about the first time you started to work for a software company.

Do you remember all the new information you had to absorb? Call to mind the culture you had to adopt, the relationships you had to form, and the entire company history you had to make sense of.

We have to work through all this information in order to do our jobs. There’s no way around it. If we don’t understand the context of our job, we can’t contribute anything meaningful.

But all of this new information can be overwhelming, especially when we have just started a new job.

As time passes, we become more comfortable with the context around us. There are two reasons for that:

1. We have internalized a good chunk of the context.
2. We got better at deciding what is relevant to us and what isn’t.

Of the two reasons, the second one is way more important. There’s an infinite amount of information, so we can’t learn everything. Instead, we must choose wisely what we want to learn.

In other words, the only reason we feel more comfortable with the context around us is because we have reduced it to a manageable size.

Aligning teams and bounded contexts

What does this mean for our teams?

Our colleagues will have done exactly the same of course: they, too, will have reduced the context around them to a manageable size.

But different people come to different conclusions about what’s relevant and what’s not. So all the members of a team will have familiarized themselves with a different slice of context.

When a team comes together for the first time, its members will share very little context. But the more they communicate, the more their understanding of the context around them will start to align.

Once a team has settled on a common language and has created a shared mental model, its members will have arrived at a shared understanding of the context too.

From that moment on, the team has basically created a kind of boundary. The information that is relevant to the team is within that boundary, everything else is outside of it. In Domain-Driven Design this is called the team’s bounded context.

Scaling beyond one team with context maps

A bounded context does not exist in a vacuum though. It is only one part of a larger system. Within that system the bounded context has a clear purpose. To achieve that purpose, the bounded context has to interact with the rest of the system.

Let’s make that more concrete with an example. Consider a restaurant. A restaurant can be thought of as a system for providing a delightful experience to its customers. An important bounded context of a restaurant is the kitchen, which is responsible for food preparation. But food preparation is not enough for a delightful experience. The kitchen staff has to interact with individuals responsible for other areas too (e.g. waiters).

Most organizations will consist of several bounded contexts that all interact with each other.

If we stop focussing on one bounded context and zoom out a little bit, we can gain a better understanding of how all the pieces fit together. We start to see the interactions between bounded contexts. By looking at our organization in this way, a new kind of structure emerges.

This new way of representing the structure of an organization is called a context map.

Context maps highlight some of the most crucial communication paths in a company. It is those communication paths that we can expect to shape the structure of our software more than anything else.

This makes them an indispensable tool for all system architects.

But they don’t just shape the architecture of our systems. They also tell us how we can scale Domain-Driven Design beyond a single team:

• Within a bounded context we aim for a ubiquitous language and a shared mental model.
• When we go from one bounded context to another we have to translate terminology from one model to the other.

We’re going to explore this topic more in the upcoming article about model refinement.