The Ubiquitous Language is not Ubiquitous

February 18th, 2010

I attended an interesting Domain-Driven Design talk today given by Janniche Haugen talking about why you would want to use Domain-Driven Design in a project, and this presentation is what triggered this post.

My statement is that the Ubiquitous Language in Domain-Driven Design is not Ubiquitous.

Lets first look at the definition of ubiquitous: Being present everywhere at once. Hmm that sounds a bit vague; here is a definition of ubiquitous language: A language structured around the domain model and used by all team members to connect all activities of the team with the software. Ah that is better. So the ubiquitous language is a common language shared by the domain experts, developers and the code.

But it is not a common language throughout all of the domain and code, this is one of the reasons why we have different bounded contexts. Because the same language may mean different things to different domain experts. Think for example about a shipping company, the meaning of the word ship is completely different when talking to accounting versus maintenance. For accounting a ship is an asset that degrades in value over time, but for maintenance a ship is an object that needs service every x nautical miles.

The same word has a different meaning when used in a different context, that is not ubiquitous.

Lets continue the small example, domain experts from maintenance also talk about an engine and rotor blades. But the domain expert in accounting don’t use these words at all, they have no meaning to them.

Some words even have no meaning at all when used in a different context, this as well is not ubiquitous.

So the Ubiquitous Language is only Ubiquitous within a given Context. What do you think?

← Older Comments
  • Scott Felder

    @Mark Nijhof
    Your ubiquitous language is the language of your domain experts. They define it and they are the owners of the language. As developers it is our job to learn their language. So if you application only focuses on one domain, say accounting, then you may only have one ubiquitous language, but if your app encompasses many different domains then you will need to learn the ubiquitous language of each of those domain within each bounded context.

    Now as I understand it, if you have multiple bounded contexts, then you would have multiple domains within your application. One for each bounded context and a unbiquitous language describing each of them.

    So as developers we need to learn to be multilingual.

  • Raymond Roestenburg

    @Mark Nijhof
    IMHO There is a difference between what a business activity concept (for lack of a better term) is (i.e. shipping) and what a domain model is (and can be) in terms of object orientation, classes and the context of those classes.

    You will never define a class based on the real object it represents with all the behavior from every perspective thinkable in reality for that object. (I have always had a strong objection to the idea that OO is about modelling after reality) A car has an engine in reality, but in my parking application I am not concerned with that. In a car assembly line application I might be concerned with it. So defining what a domain is about, is exactly what the ubiquitous language for that domain is about, what is important for that domain, and what is not, and which slice we model.

  • http://aslamkhan.net Aslam Khan

    Hi Mark,

    The ubiquitous language is not the language of the domain experts. It is the language that is agreed upon by the developers, the domain experts and any significant stakeholder. Also, it is not chosen up front, but it evolves as understanding and insight is increases. So, you harvest and refactor your UL.

    True, it *may* be different in bounded contexts, but it is likely that the language in one context has some semantic equivalence (to some degree) in the other context. And in your examples, perhaps the choice of contexts does not promote the UL, and it would be a better strategic design to not create contexts bounded around departments in the organisation. That rarely works, in my experience.

    Finally, the ubiquitous language is the sum of languages in all contexts. If you fragment it without doing some form of semantic equivalence, it will be hard to achieve any context mapping at all, apart from moving down the road of the separate ways pattern or single bounded context. That in itself, is not necessarily bad, but you need to determine if it is valuable.

    Such a simple thought, yet so much of discussion. Interesting :-)

    – Aslam

← Older Comments