Domain-Driven Design is a large topic and a study on itself. Applying all the concepts has a steep learning curve. However, a few concepts can quickly enhance a project; one of them is, Ubiquitous Language.
Ubiquitous Language
“A language structured around the domain model and used by all team members to connect all the activities of the team with the software.”
From: Eric Evans. “Domain-Driven Design: Tackling Complexity in the Heart of Software”.
To start off, everybody in a team needs to have the same idea of what a domain model is. If you’d ask a database expert what ‘the model’ is and you might get an Entity Relationship Diagram (ERD). Ask a programmer what the model is and you might get to see some Unified Modelling Language (UML) or just a bunch of boxes ’n arrows. While on the other hand, a domain expert might draw up a flow diagram. But actually, the domain model is not a specific diagram. It is the idea that the diagram is intended to communicate. Sure, you could use a diagram to communicate that model, but you could als use common written language or programmers code. A domain model is not about technical details, not about objective inheritance, foreign keys and such. It is an abstraction of domain knowledge in a well organised manner. It’s a semantic model that can be applied to different technical implementations while staying the same.
Experts have their own jargon. It helps them to communicate better and more concise between one another. However, when various experts work in a team, this causes the language to become fractured. A domain expert usually speaks functionally and descriptive about business processes, solution requirements and such. Amongst developers, people create technical visualisations and texts to explain their understanding of the solution [part] that they’re working. However, nothing describes the logical business model in a way that can be used to accurately communicate it across experts in a common understanding. This results in lots of translation going on between team members, but also between teams and domain experts. Developers can have a hard time understanding the domain they are unfamiliar with. There are a few might ‘get it’. They learn to understand and speak both languages. All too often those people are placed in a role (e.g. “The Architect”) and given the responsibility to help with the translation. They become the first point of reference for the domain experts and technical team members.
A project team without a common language usually copes with the following challenges:
- Information is lost in translation
- Information can be given a wrong meaning, depending on the interpretation of the translator
- It may result in many different interpretations of the same concept
- The few that have deep understanding about the domain and the technical solution become a bottleneck and therefore a liability for the project
- High cost of overhead while explaining concepts over and over again to one another causes communication fatigue
- Low cohesion between domain experts and technical staff
- Refactoring of code becomes destructive if tedious, which results in low quality code and unreliable software.
To completely have everybody speak the language of the domain experts or the other way around is counter productive, if not impossible. Each language on its own does not serve all needs. Using the similarities between them does not create a vigorous language either. The ubiquitous language evolves from the domain model when the team is committed to using a common vocabulary. This includes names of operations, features, classes in the model. It includes the business rules and patterns that everybody agrees upon. The words and phrases that are used describe the semantics of the domain model. The model-based language given is a tool for domain experts and developers to communicate with each other and talk about requirements, features and planning. By using the language the model is better understood. When that language is used consistently, inconsistencies and contradictions can be discovered in the model. This could trigger a change in the model. Subsequently, that can trigger a change in code, names of classes, patterns etc.
While it takes time and persuasion to build up an Ubiquitous Language, it is defiantly worth it. You will quickly see that model discussions become more concise. Requirement refinements in agile projects are done more efficiently. Since the model is mirrored in the code base, it becomes easier to understand and refactor. Every project can benefit from that.
Eric Evans’ book “Domain-Driven Design: Tackling Complexity in the Heart of Software” covers Ubiquitous Language is more detail in chapter 2 “Communication and the Use of Language”.