Driving and refining Ubiquitous Language

This post was originally published here.

Scott has a nice succinct description of how Ubiquitous Language is defined.  In the original description, Eric defines Ubiquitous Language as:

A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

But unless the model is created through user stories with a domain expert, the domain model doesn’t necessarily represent what true concepts in the domain, but rather concepts through the emerald-colored glasses of the developer.  Language drives the model, the model can represent the language, but the model never drives the language unless through user stories.  If you find that the domain experts are using language that only exists because it exists in the software, you’ve made a wrong turn somewhere.

It can be easy to fall into the trap where the domain expert becomes so familiar with the software and the model, that they start defining their language from the software.  That’s where the skills of the developer and modeler become even more important.  The developer needs to recognize both gaps in the language and compromises by the domain expert to fit their ideas into what they already see in the system.

So how do we make sure the language doesn’t get corrupted by the model or the system?  A few things need to be in place in your team:

• Honesty
  • Trust
    • Communication</ul> The domain expert needs to be honest about irregularities, the developers need to trust the domain expert to be honest, and lots of communication needs to happen to build honesty and trust.