ALM Practices Part 9: Ubiquitous Language

What is it?

The Ubiquitous Language is a unified language consisting of verbs and nouns from the business domain of an enterprise system and should be used by all team members, stakeholders and other involved persons.

Why would you do it?

• Because it creates a bridge of understanding between the developers and the business people.
• Because it forces different stakeholders (possibly working in different departments) to use the same name for the same concept.
• Because it improves the readability of the domain model for both developers and business people.
• Because it improves traceability from functional design, through the user interface all the way into the details of the code base.

What’s the usual thing to do?

• Maintain a list of verbs and nouns from the domain and promote its usage during verbal communication, in documentation, in user interfaces, and in the entire codebase.

How do you do that?

• Let the business people propose a proper verb or noun for the concept.
• Be aware of the fact that different stakeholders may use the same name for different concepts, or different names for the same concepts. Make sure they choose a single unique name for each individual concept.
• If a name conflicts with a common engineering concept and serious confusion is expected, consider proposing an alternative name.
• Unless it is company policy to communicate in English, write your domain model in the native language of the business stakeholders.
• If your policy is to write code in English and the Ubiquitous Language is in your native language, create a glossary that maps the verbs and nouns from the native domain model into the English translations. Be very pro-active in enforcing these specific translations, because from experience I know developers have a tendency for coming up with alternative translations.
• Be aware of names that are often used intertwined, but represent the same concept. Force one word for that.
• Be aware of concepts with multiple intentions. They may be different things and require different entities in your domain model.
• Also be aware for a concept that appears to have mutual exclusive business rules in different circumstances. In most cases, introducing different concepts (and thus different entities) can prevent significant maintenance burden and confusion.
• If, throughout the project, you come up with a better name for a concept, make sure you adapt your entire code base, functional documentation and the application itself. If you don’t, you end up with many different names for the same concept, causing significant confusion in the project.