Domain-Driven Design is first and foremost about teamwork

About eight years ago, I came across the concept of Domain-Driven Design (DDD) for the first time. Back then, I was still working in a tiny startup with only a handful of developers. And although I did learn about entities, aggregates and the like back then, I completely failed to understand that DDD really is about teamwork.

The importance of mental models

Let’s suppose you sit down to change an existing piece of software. What’s the first thing you do? I would argue that all of us begin with the construction of a mental model.

To build that mental model, we choose to perform a variety of activities. Depending on the situation we might study the source code, talk to our colleagues, create diagrams or, perhaps, even modify an existing suite of automated tests.

In doing so we pick up and internalise plenty of information about the piece of software we are trying to change. We look for answers to questions such as:

• What is the existing behaviour?
• What constraints do we face?
• What is the software’s structure?

As we fill the holes in our understanding we automatically construct a mental model. Once that mental model is good enough, we can begin to make the desired changes. Before that, we wouldn’t know what to change.

Two teams, one difference

If we accept that mental model construction is an unavoidable step in developing software, it follows that software development will be more efficient the faster we can form a good enough mental model.

Is this true? My own experience suggests that it is indeed.

I had once been of assistance to a team that had just inherited a new piece of software and was hoping to make some changes. In a casual conversation the product manager asked me how our products were handling a particular kind of license. Although I didn’t know the answer, I promised to look for it. After the conversation I fetched the source code and searched for the exact terms my colleague had used. Ét voila - I found what I was looking for almost immediately and after just one glance I had the answer that my colleague was looking for.

What a remarkable experience! Think about it: the two of us were able to solve a business problem together although none of us had ever seen the code before. One conversation and a few minutes were enough for me to build a mental model of an unfamiliar piece of software, to find out exactly what the computer was instructed to do, and to explain that piece of code to the product manager. Building a mental model was almost effortless.

On another occasion, after switching teams, I was trying to familiarise myself with a new code base. Despite my best efforts, it appeared that I just couldn’t fit all the relevant details into my head. Several things were preventing me from building a mental model: While the customer facing documentation was using one set of terminology, the strategy documents, plans and road maps where using another one. The components that the architecture diagrams referred to didn’t actually exist. And, perhaps the worst of all, throughout the entire code base the names had been mixed up. Things that were the same had different names while things that were different had been given the same names.

Later it occured to me that the majority of my brain was just busy translating between concepts. It’s probably no surprise that it took me a long time to build up a sufficiently good mental model.

Now, what do you think: which of the two teams got changes to market faster? Which one was able to incorporate more customer feedback? Which one achieved the better outcomes?

I think the answer is obvious.

The benefits of a shared model

But what was causing such a big difference between the two teams? Why was it so easy to form a mental model in the first team, yet so difficult in the second team?

The first team had something that the second team didn’t have: a shared mental model.

Just by looking at the source code of the first team I could tell that they had all worked together to build a single shared model of the business domain. They had picked a set of terms all related to the business processes they were modelling. They had made sure to use those terms in a consistent fashion throughout all of their communication. They had designed their software around those terms. Everyone on that team, including the developers, the product mangers, the content designers and all the other roles involved in making software, had come together to build a shared mental model. It was that very mental model that the developers had turned into code (and not just their own models).

The second team, however, did not have a shared mental model. Instead, everyone on that team had created their own mental model of what they knew best about. Since the developers had written the code, their mental models got embedded into the code. Since the plans had been created by the product managers, it was their mental models that one found in the roadmaps. To make sense of anything, one first had to understand everything.

It was the shared model that made it so easy for me to understand the code base of the first team (and the absence of said model in the second team that was making it so difficult).

The difference in productivity that a shared model brings can hardly be overstated.

But, of course, I am not the only person to have realized this. In 2004 Eric Evans published his book “Domain-Driven Design: Tackling Complexity in the Heart of Software”, in which he stated:

“On a project without a common language, developers have to translate for domain experts. Domain experts translate between developers and still other domain experts. Developers even translate for each other. […]. The overhead cost of all the translation, plus the risk of misunderstanding, is just too high. 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.”

It is this idea that has made Evans’ book not just widely successful, but has also spawned an entire community around it. Let’s get right to the bottom of it: teamwork is what makes a shared mental model possible after all.

The language we use as a team plays a central role in our efforts to build a shared mental model. That’s why we’ll look into the concept of a ubiquitous language in the next article.