Yes, sort of …

It *is* Ubiquitous, in that it does exist everywhere at once, but when you are within a bounded context, there is *nothing else* and therefore it is ubiquitous …

This is something I am thinking these days. When I think about Ubiquitous Language, I found using the Accounting as a reference model to be helpful for me to understand it. Terms like profit or cost means very different things under sales, finance, manufacturing contexts. The accounting model however, have standardized the relationship and have given specialized accounting names for each profit under a specific context. Another example is CRM, just to model the definition and lifecycle of ‘Customer’ and ‘Contact’ are not the easy job. That’s why I think that is what DDD means for ‘ubuquitous’ language – the language should be shared and mutually understood. That includes not only the meaning of the terms, but how the concepts varies under each context, and the mapping/relationship between these different meanings.

The business people only know the meaning that apply to them. As developers I guess we have to be the caretakers of the ubiquitous language, and keep a definition spanning all the different context. Internally we should probably talk about stuff like Accounting::Ship and Maintenance::Ship, and use the appropriate versions when talking to each of the departments.

If people in two different BCs do not work closely together how is it possible to come up with global UL? I think the UL will be shared at points where the people share the same model (Shared Kernel).

Some domains are very complicated and if we choose some characteristics of a domain concept in one model but other characteristics in another model using the same domain name for different set of characteristics will be obscuring.

Btw, Eric called these different languages in different BCs ‘UL dialects’. So, still one UL that has different dialects.

“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.”

I would say that you are talking about two different domains here (accounting and maintenance). When concepts are going to mean different things (or do not exist, or difference in relevance) to different people, I would say that to be indicative of domain boundaries. I like this link (who would have guessed for a quick reminder of the intent http://martinfowler.com/bliki/UbiquitousLanguage.html. Without an ubiquitous language there is no strict way to define the model in clear terms, which are both understood by users and developers.

1 to Raymond. Mark, you are talking about different domains, not boundaries. I do not think that this is good idea to model them in single code-base, and store in single database (this is possible though).

@Jak
Right so if I interpreted you correctly then without the Bounded Context the ubiquitous part is absolutely true, but there is no single language in the domain, because the domain consists of different bounded contexts.

@Vitaly Stakhov
I would argue that different dialects is a bad way of describing it, because usually a dialect uses different words to describe the same thing, here we use the same word to describe different things.

@Raymond Roestenburg
@Mike Chaliy
Hmm I would say that they are in the same domain (shipping), but in a different bounded context. You usually put the different bounded context into different assemblies (or whatever you are using).

Btw I am not arguing against defining the ubiquitous language at all, I just have trouble with saying it is one language.

You’re true that it would be a mistake to think that a signle Ubiquitous Language would span all the models.
That would become an enterprise model then… very bad idea : there are always multiple models.

@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.

@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.

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