Domain-Driven Design: towards a ubiquitous language
Last week we’ve learned how beneficial a shared mental model can be to a team, especially when that team is in the business of developing software. Unfortunately, I noticed that many teams don’t have a shared mental model. This observation raises an important question: how can we facilitate the construction of one?
Today we will try to answer that question by introducing one of the fundamental concepts of Domain-Driven Design: ubiquitous language.
Settlign on a shared model
Most of the teams I was a part of didn’t have a shared mental model. Instead, almost everyone on those teams had come up with their own mental models.
You see, the problem never was a lack of mental models. Typically, there were as many mental models as there were individuals on the team. The problem always was the abundance of mental models, many of them in conflict with each other.
Consequentially, a team without a shared mental model has to align all of the existing mental models and reduce their number back to one. To do so, we must get all of the team’s members to communicate with each other.
Communicating abstract ideas
As human beings we have exactly one tool to communicate ideas as abstract and complex as software: our language.
But although language is our only tool for the job, it is also far from being perfect. Communicating with language has two fundamental problems:
- It takes time.
- It is prone to errors.
Let’s assume I have an idea that I want to share with you. You and I get together and the following conversation takes place:
Me: I just understood how we can represent licenses in our app!
You: Which app?
Me: Our latest shiny SaaS product!
You: Ah okay, sounds great. But don’t we already have support for licenses in that one?
Me: Yes, of course we do, but we only have perpetual licenses - up until now. I know how we can represent annual licenses too!
You: Ah, so a form of subscription then? Have you considered free licenses already?
Me: Free licenses? I thought having a license is equivalent to having a paid subscription?
You: That’s not how I understand it. As I understand it, free apps have a free license. None of our products is ever without a license.
Me: Ah, I hadn’t thought about it this way. I need to think about this a little more then.
What’s happened in this conversation is fairly typical: One person makes a statement that is obvious to them, but confusing to the other person. The first person realizes this and adds more context. Then they go back to the previous statement, where another question pops up. And so, through a series of back and forth, they understand each other better and get closer to a shared mental model.
Now, this was only a brief conversation and the participants only had a little misunderstanding that they had to resolve. So they managed to align their understanding fairly quickly.
But if you consider the enormous complexity of the kind of software that most teams are working on, you’ll be able to imagine how difficult it can be to align an entire team.
Two strategies can help us cope in the more difficult situations:
1) When possible, we use a high-bandwidth, low-latency medium like a face-to-face conversation instead of low-bandwith, high-latency mediums like written text.
1) When we discover a new concept that we refer to a lot, we introduce a name for it and subsequently use that new name with our peers. We repeat this process as we learn more.
Over time, we develop an entire system of words and concepts all related to each other in some way. Eventually, we are able to refer to something as complex as a motorcycle with a single word. Amazing!
“That’s all the motorcycle is, a system of concepts worked out in steel. There’s no part in it, no shape in it, that is not out of someone’s mind.” — Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values
Unfortunately, this powerful tool for aligning mental models has a downside too, especially if we are not intentional in its use.
Jargon considered harmful
Have you ever been to dinner with a group of doctors and listened to them talking about their work? If not, how about lawyers? Or accounts? Or, really, any other profession?
If yes, then you will know this particular feeling when the conversation starts to be dominated by words you don’t quite understand. Sure, some of the words may appear familiar to you, like hypertensive intracerebral hemorrhage or idiopathic pulmonary fibrosis. But what exactly they mean – no idea. Everyone seems to be having a great time though and so, being polite about it, you start to tune out.
Every profession has its own specialized terminology, its own jargon. Jargon is great, because it allows a group to communicate more effectively, especially because it makes it easier to transfer abstract concepts.
However, jargon’s biggest downside is that it excludes all those from the conversation who don’t understand it (this is exactly what happened to you at the dinner party).
Here’s another example. If you’ve done some Java programming, chances are that this little poem will bring a smile to your face:
Roses are red, leaves are green, but only Java has AbstractSingletonProxyFactoryBean — bash.org
Don’t worry if you didn’t understand the poem though. You didn’t miss anything. In fact, you might even be a little further ahead, because you’ve just experienced the excluding force of jargon first-hand.
A common language for the team
To develop software, we tend to bring in people from a wide range of professions. We often depend on the specialized skills of software developers, user experience designers, interface designers, product managers, content designers, legal, compliance, support, and many more. For our software to be successful, all these people need to work together.
But working together is not easy. We don’t really learn it in school. We get graded individually. Collaboration is often discouraged, perhaps called cheating. Later we move on to specialize in a profession. Surrounded by peers practicing the same trade we pick up two things: a new set of skills and our profession’s jargon.
Up until this point our specialized language has been of great use to us. But the moment we join a cross-functional team our specialized language can become a hindrance.
I’ve observed a particular pattern repeat itself over and over again in countless meetings:
- Developers, product managers and designers get together to discuss a problem.
- Someone gives an introduction to get everyone on the same page.
- A balanced discussion between design, product managers and developers begins - everyone uses the language of the customer and of the problem domain.
- At some point the developers dive into the details of a particular topic. Technical jargon like microservice, GraphQL or RDS enters the conversation.
- The product managers and designers try to follow the conversation at first, but soon stop paying attention, because they can’t follow.
- Eventually the developers are the only ones participating in the conversation, making ad-hoc decisions about the product and the design without anyone (including the developers) noticing.
And with that a great opportunity for settling on a shared mental model with the entire team is lost. Although everyone is present in this kind of meeting, the difference in language is the biggest obstacle to the team’s effectiveness.
If our goal is to get the best of everyone into everything we do, we can’t have obstacles like those though! What our teams need is a common language. A language that allows everyone to participate in problem solving. A language that facilitates the construction of a shared mental model.
Once a team is commited to establish a common language, they will invariably begin to use that language everywhere. You’ll see it reflected in source code, in customer-facing documentation, in plans, in meeting notes and everywhere else.
At that point the language has become ubiquitous.
But how can a team get to a common language? Excellent question! We’re going to find an answer in the next article.