Dear Junior
Most people agree that the domain and the domain model are two different things. Thus it is logically possible that the domain language is not the same as the domain model language. Yet, there is a lot of confusion in this area, especially in relation to what we in Domain Driven Design call the ubiquitous language.
That the domain and the domain model are not the same seem to be as obvious as that reality and a map are different things. So, it is qurious that as soon as you add "language" into that mix things get confused.
What is a Language?
As "language" seem to be a confusing construct, let us start out with thinking about that. Of course there are truckloads of ways to define language, but if we pick a few from the web we get
Merriam-Webster: (2) a systematic means of communicating ideas or feelings by the use of conventionalized signs, sounds, gestures, or marks having understood meanings
Princeton WordNet: a system of words used to name things in a particular discipline: "legal terminology"; "biological nomenclature"
In the Princeton definition I like the "in a particular discipline" that points out that a language is not necessarily "English" or "Swedish", it can be a "sub-language" as used by lawyers or researchers as well. In the Merriam-Webster definition I like "signs having understood meaning" that describes a "fit for purpose" sense, languages are for transferring understanding.
Taking these together gives something along the line of defining language as "the context in which words and phrases are understood to carry a particular meaning". I guess the Wittgenstein ideas of "Sprachspiel" in Philosophische Untersuchunge comes pretty close to what I am after.
The most important part to me is that the language has a purpose, the purpose to communicate ideas within a particular context, and within that context a meaning is understood – the purpose fulfilled. Wittgenstein takes this one step further and Philosophische Untersuchungen can (somewhat trivialized) be summaries with "Meaning just is use".
A wonderful example of this is pidgin languages, which evolve when two parties with one native language each meet and need to communicate. Then a new language emerges, which borrow vocabulary and grammars from either or both languages.
Swahili as an example was born (as I have understood it) when Arab traders traveled the East African coast trading with bantu tribes, and over time a trading language emerged which takes a lot of its vocabulary from the bantu languages but borrows a lot of grammar from Arabic. Since then Swahili have grown to a native language of its own.
The point here is that Swahili emerged to fulfill a purpose, to enable east African tribes and Arab traders to exchange goods and ideas.
The Purpose of Domain Language and Domain Model Language
Domain experts need to communicate to solve problems in their everyday work. To do that they have evolved a language that fits that purpose – the domain language. It is probably based on some natural language such as English (or Swedish). However, it is definitely not "just English" any longer, which is obviously clear if you happen to step by and overhear a conversation between two domain experts. It is full of strange terminology and might sometime violate "ordinary grammar", but it fulfills its purpose: enabling domain experts to work efficiently together to solve problems within the domain.
The domain model language has another context and another purpose. Here domain modelers (i e everybody involved in modeling) try to work out models that address as many of the relevant problems as possible. So the purpose is to create a terminology that is precise enough to build a system that automatically can handle a lot of situations.
So the domain language and the domain model language both have different context, and fulfill different purposes – so it should be no surprise that they are different.
However, I often see them mixed up, and I think the problems are most of the time of two types: either thinking the domain language is the domain model language, or that the domain model language should be the domain language.
The Domain Language is not Fit for Use as Domain Model Language
A very naïve approach to modeling is to just ask the domain expert "how things work" and write that down as a model. This does not work very well as there is no ready-baked domain model inside the head of the expert., simply because they are not consciously aware of the nature of their expertise. The language analogy of this is to take whatever the domain expert say and use that as the definition in the domain model language.
The problem is that domain experts are not that strict – simply because they have no need for it. They can use words without defining a precise meaning, and it does not matter – because to the other domain expert the meaning will be clear from the context. So, the domain language is filled with ambiguities, inconsistencies, and contradictions.
In other words, the domain language does not work very well as a language for the domain model.
The Domain Model Language is not Fit for Use as Domain Language
The other mistake is to think that once we have created a terminology in the domain model, then that terminology is what should be used always and everywhere when talking about the domain. After all, we call it the ubiquitous language – don't we?
In fact I have seen this taken so far that programmers have tried to "educate" the domain experts to use the term from the glossary – actually correcting them when overhearing discussions between domain people. This is a misunderstanding of purpose. The purpose of the domain model language is to be able to discuss precisely about the system we are building – not to create a "language police" to enforce a more precise language in general.
To defend the domain experts – their liberal use of words are not them being sloppy; especially not as opposed to "structured" programmers. It is the nature of a conversation where the focus is at a much higher level, and there all ambiguities are either clear from context or can quickly be resolved.
If you thought programmers where "strict", then take a chance to listen to two expert programmers discussing an object-oriented design. This is nothing but a domain-expert conversation between two experts on object-oriented design. What you will hear is an astonishing "sloppiness": they are using the words "object", "instance", and "class" almost interchangeable, as if they where synonyms.
But this "sloppiness" is not a problem, because the discussion was about making distinction between "objects" and "classes". The purpose was to discuss designation of responsibilities, conditions on contracts and co-operation between components. The precise meaning of each word does not matter that much, context will provide the "error-corrections" that are needed.
It is not even sure that we would want domain language to be precise. There is some really interesting research in cognitive psychology that (trivialized) can be phrased as "what you cannot express, you cannot think". This has the interesting implication that it is actually the ambiguities, inconsistencies and contradictions that enable misunderstandings and thus new ideas. So, the "flawed preciseness" is really the fundament for creativity. Insisting on using the precise domain model language as the domain language would kill that creativity.
In other words, the domain model language would not work very well to use as the domain language.
Relation between Domain Language and Domain Model Language
Of course, the best source of inspiration when building a domain model and creating its language, is the domain language. However, I think it is important to make the distinction explicit.
Talk with your domain experts and tell them that "we are not trying to be a language police, but when talking about the system we need to be very precise". And when modelling, do ask: "can we use announcement to refer to [some strict definition] and notification to refer to [some distinction] when taking about the system"?
The Ubiquitous Language
If there are several languages around – then what about the ubiquity?
Well, the "ubiquity" in the "ubiquitous language" refer to that we only have one language to talk about the system, and that everybody involved (domain experts, programmers, GUI designers, DBAs) understand and express him or herself using that language, when talking about the system.
Of course all these will talk other languages in other contexts – the DBAs will have their lingo when discussing database structure, programmers will mess up "classes" with "objects" when discussing design, and domain experts will use the domain language discussing among themselves.
However, when coming together to discuss the system they have agreed on a pidgin language which is very limited in "reach" (talks only about the system), but very strict within that bounded context. And there is only one such language – the ubiquitous language.
Yours
Dan
ps Establishing a new term in the ubiquitous language is had work and full of traps, but it helps to keep ubiquitously shared, context-bound, and strict in mind helps.