Domain-Driven Design: the limits of ubiquity

In discussing the benefits of a shared mental model we always did so in the context of a team. But many organisations consist of more than one team. Can we take the ideas of Domain-Driven Design and apply them to an entire department or even the whole company?

How far can you take an idea?

Once I had experienced the compelling benefits of a ubiquitous language first-hand, it didn’t take me long to ponder how far I could take the idea. Would it be possible to get my entire department – a group of about 70 people – to settle on one set of terminology?

Intuitively, I would have answered “yes”.

In my understanding the term ubiquitous language meant the same as one language shared by everyone. At least that’s what stuck after learning that ubiquitous is another word for omnipresent.

When I tried to devise a plan for getting everyone to settle on a common language though, I realized that I had a herculean task in front of me.

Establishing a common language in large groups

As we discussed in the previous article, the most effective way to establish a common language in a group of people is to increase collaboration. By getting everyone to work together, we can expect the group’s language to align automatically.

Now, of course, collaboration requires communication. The members of a group must exchange information to ensure that everyone is working towards the same goal. Otherwise, all the individual contributions just won’t fit together.

For a ubiquitous language to develop in a group, we require each member to communicate frequently with every other member.

We can turn this statement into a graph by representing each member as a node and each possible communication path as an edge.

If we count the number of communication paths for increasing group sizes, we can spot an important detail:

• A group of two has exactly one communication path.
• A group of three has three communication paths.
• A group of four has six communication paths.
• A group of five has ten communication paths.

The number of communication paths grows faster than the number of members!

Drawing these graphs and counting all the edges by hand is a little tedious though. Luckily, we don’t have to keep doing this. It turns out that the number of communication paths can be calculated with the following equation:

Let c be the number of communication paths in a group of size n, then

c = n * (n-1) / 2

Here’s another way of expressing the equation:

“The number of possible communication paths in an organization is approximately half the square of the number of people in the organization.” — “How Do Committees Invent?”, Melvin E. Conway

We can also gain a bit of an intuition about the equation by plotting it:

Do you see how quickly the number of communication paths grows when the group size increases?

A team with five members has only ten communication paths. But a whole department with 70 members has a staggering 2415 communication paths.

Can you imagine how much time it would take a group of that size to settle on a ubiquitous language?

If we optimistically assume that the group only needs to spend one hour a week for each communication path to form a ubiquitous language, then the group would have to spend 2415 hours doing nothing but communicate. That’s about 86 percent of the available 2800 work hours (assuming everyone works 40 hours a week).

What a high price to pay for a ubiquitous language, especially if you consider how little time would be left to get anything else done!

But what about ubiquity?

So, my intuition turned out to be wrong after all. It wouldn’t be possible to get my entire department to settle on one set of terminology.

But what about the term ubiquitous language? Didn’t ubiquitous (or omnipresent) imply that we should aim for just one language shared by everyone?

I went back to the original Domain-Driven Design book to check the exact definition, only to discover I had misunderstood a fundamental concept of Domain-Driven Design:

A project needs a common language that is more robust than the lowest common denominator. With a conscious effort by the team, the domain model can provide the backbone for that common language, while connecting team communication to the software implementation. That language can be ubiquitous in the team’s work. — “Domain-Driven Design: Tackling Complexity in the Heart of Software”, Eric Evans

Can you spot the difference?

The term ubiquitous language isn’t supposed to mean “one language shared by everyone”. Instead, it means “one language shared by one team, but present in all of the team’s work”.

It’s a small detail, but an important one to understand.

Summary

Our original question remains: can we take the ideas of Domain-Driven Design and apply them to an entire department or even the whole company?

As we’ve seen, getting a large group to settle on one set of terminology is a herculean task destined to fail.

However, there is a way to allow large groups to benefit from Domain-Driven Design!

To understand it, we need to learn about bounded contexts and context maps first.