There have been some interesting discussions recently about the importance of having a “common language” between developers and business domain experts. DDD refers to this concept as its “Ubiquitous Language”:
“The concept is simple, that developers and the business should share a common language, that both understand to mean the same things, and more importantly, that is set in business terminology, not technical terminology.”
The intention is that once we share a common vocabulary, we can improve our requirements and design. The class design (the business entities and their relationships) hopefully better reflects the true interactions of the business we are trying serve.
The Problem / An Example
The difficultly in identifying the “real names” typically lies somewhere between developers and the business domain experts. However, on some very large projects, I seemed to have encountered another variation of this problem.
Let’s consider a large project, divided into multiple teams. Each team is responsible to design and implement separate functionality, but each team has significant overlap with the other.
For example, imagine Really Big Company’s executive management has decided to build an “improved” customized version of their current email system to communicate better with customers. So, in assemblies our project teams, we decide to divide the project into two primary teams: Team A will build the “inbox” functionality, and Team B will build the contact management module.
Since Team A and Team B follow good DDD principles, they being working on creating their common language (shared names). Team A discovers that the domain experts for the Inbox system refer to their mail recipients as “contacts”, and, ironically, Team B’s domain experts refer to their contacts as “customers”.
At some point, they realize that “customers” are really just one “type” of contact. With this shared understanding, the developers create a design where [Customer] will be a subclass/child of [Contact]. The domain experts readily agree the improved design.
So now, developers will distinguish contacts from customers. And the next time they hear domain experts refer to a “customer”, they think they can assume a[Customer]. The business agreed on it, right?!
So, the real question — did the business user really mean [Customer]? Or did they really mean [Contact]?
It is unlikely that the vocabulary of the business users will change, especially when the business users are not part of the full time project staff. Remember, the developer staff isn’t the only interaction that these domain experts will have! So, even when we have “agreement”, it is unlikely (and probably undesirable) to change the language of the business.
So then what?
After all this, we may be tempted to throw out our ideas on common language, shared names, and ubiquitous language. However, let’s stop to see what we have accomplished.
In our theoretical meeting, when the domain expert mentioned “customer”, the technical team can now ask “Do you mean [Customer] or [Contact]?”. And, with any luck, the business now understands what we mean, and can give a simple answer. “Ah, yes, you’re right. I do mean [Contact]”.
Common language isn’t a cure-all. But it sure helps.
I’m curious to hear your experiences as well.