Domain Language and Domain Model Language are not the same

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.

The Domain Model is not in the Head of the Expert

Dear Junior

Among programmers it is not uncommon to get into discussions on naming of variable, methods, classes etc. A pretty common way to resolve these discussions is to say “let’s ask the domain expert”. Even though I encourage communication across disciplines, there is a sub-tone that alarms me: the sub-tone of “checking the answer”, like if the proper domain model was in the head of the domain expert, and the task of the programmers is to uncover it and write it down in code. I think this surfaces two different misconceptions about domain modelling in general as understood by domain driven design.

The first misconception is the kind of expertise the domain expert has. He or she might very well be an expert stock trader, online campaign marketer, or transportation router – but that expertise is about performing tasks within the domain, not necessarily to think and reason about the domain. This is analogous to the difference between doing a left turn on a bike, or to explain how to make a left turn.

To put it another way, most domain experts are not consciously aware of their expertise. Of course, they probably are aware that they are experts – but they are not aware of what makes them experts – the same way most people don’t know why they can make a left turn. So, asking them to give a model will probably just give you a “first order approximation” or a naïve model that will hold for “typical” cases – but will probably break down when things are getting a little bit trickier. Key phrase for spotting this is: “Oh, well, of course, if the shipping organisation [whatever] is actually the ordering organisation [whatever], then there of course shall be no transit-through fee [obviously not …]”.

At one project I entered there where some severe confusion on the tech side of what went into a “notification” as opposed to an “announcement”. Different tech people had talked to the domain experts and this had resulted in inconsistent requirements. The approach to “ask the expert” had been used several times, but the confusion had only gotten worse. After a while I realised that the domain experts where not aware of the difference themselves – to them the two nouns where more or less synonyms and used interchangeably, because the precise meaning was obvious by context. They where perfectly able to handle any “notification” or “announcement” but could not verbalise a precise distinction between the two – that took some serious domain modelling to work out.

The domain experts are experts in the domain, not experts in modelling the domain. Domain modelling is a separate skill set, and that is why they need you to help them out. They simply cannot do it themselves. So, the proper way is not to go “ask the domain expert”, it is to go “work with the domain expert” to see what domain you can come up with in mutual cooperation.

Naturally there are exceptions. If a domain expert has spent considerable time and effort thinking about the domain, they might well have reached a knowledge depth that enables them to model the domain. To spot that kind of domain expert, keep your eyes open for signs that he or she has spend explicit efforts on verbalising the domain. The expert might have e g worked as an instructor in the field, given presentation for larger auditoriums such as at conferences, or might have written articles or books on the subject. If you spot such an expert; grab, hold on, and do not let go – this is a gold mine.

The second misconception in “model in expert’s head” is even more fundamental. Central to domain driven design is the attitude that models are evaluated by their usability (as in “fit for purpose”). A model could in a philosophical meaning be “true” or it might “cover a lot of the world” – but those properties are simply uninteresting. What counts is if the model can handle the cases you have at hand, and doing so in a simple way.

In other words, for the set of behaviour (“stories”, “use cases”) we have, there are an infinite number of models. Of those, none is “the right”. On the contrary, there might well be an innumerable number of models that all give the correct behaviour, and the way to discriminate between those is to find those that seem simple, in other words using Occam’s Razor.

It is logically possible that there might be several domain models that all fulfil the correct behaviour, and where none of them can be said to be simpler that another – they are all simple, but in different and incomparable ways. Then, any of these will do as a good domain model. So it is not logically necessary to search in the head of the expert. Instead let us investigate a lot of options (possible models) and select from those.

This also sets the tone of how I prefer to work with the domain experts. Instead of focusing on one model, I try to come up with several optional models that I see would fulfil the requirements, and then ask the domain expert for gut feeling. Best way to do this is a few people in a small room with a whiteboard with a lot of “generate and test”, i e find up a few models, ask for opinions, try them out on some scenarios, watch the reaction of the expert, throw away those models that where less promising, come up with some variants of those we kept, etc.

To know how long to continue this evolutionary modelling, Eric Evans has a rule of thumb I like: “keep modelling until you have created three really bad ideas”. As long as you just create good models you are probably not creative enough. It is the generation of bad ideas that prove that you have been pushing the borders.

In conclusion: I do not think there is a domain model in the head of the expert. Firstly, it is improbable because the domain experts are in general not aware of their expertise. Secondly they are not skilled modellers (their expertise is elsewhere), so the model you get by asking is often very naïve and incomplete. Thirdly, even if there would be a model there, that model has no advantage over any of the other possible models that fulfils the same purpose.

So, the way to communicate with domain experts to create a domain model is not to “ask them” it is to “work with them”.

Yours

Dan

ps When asking if someone "knows" something, if you then require them to understand the subject in depth, then most people do not know how to ride a bike.

Most People do not Know How to Ride a Bike

Dear Junior

Of course most people can be claimed to know how to ride a bike. The proof is simple: give them a bike and watch them without instructions mount onto it and take a ride without falling of – even in tricky conditions such as bumps or on slippery surface. However, the notion of “knowledge” is a little bit trickier than that, and a too “binary” notion of knowledge hurt us.

For example, take anyone of those that “know” how to ride a bike, and ask them to explain how to make a left turn. Chances are high, that you either will get no answer at all, or an answer that if followed will make you fall over - which in a pragmatic sense can be judged to be “wrong” or at least “incorrect” (did not cause the desired effect).

In the same way I can ask about myself: do I know “Java exceptions”, “EJB 3”, “agile system development” or “project management”? And when reading CVs I am regularly frustrated over just being given a long list of acronyms and frameworks; a list that tells me nothing about whether this person has been to a one-day class on Hibernate, or if she can wrinkle out modelling mistakes that will hurt performance.

For my own use I like to view knowledge not as binary (“know” vs “not know”), but rather as having levels of “depth of knowledge”. A main source of inspiration is Benjamin Bloom’s taxonomy. He defined six levels of “cognitive learning” (knowledge, comprehension, application, analysis, synthesis, and evaluation).

However, when applying this to system development, I usually collapse the three deepest levels (analysis, synthesis, and evaluation) to one, ending up with four levels. The reason for doing this is that I seldom see the need to distinguish between the deepest three, but often want to point out the difference between the first three (knowledge, comprehension, and analysis) in relation to the four latter stages. I guess a cynic might point out the choice of collapse as an observation of the state of our industry.

One thing I really like with Bloom’s taxonomy is its focus on utilisation of the knowledge. It quantifies by measured in the abilities to process and use information in a meaningful way, simply by telling what you can do at a given level. Note here “utilisation” and “measure” – two words that strongly align with my affection for pragmatism in software development.

With each level there are a couple of typical verbs attached – things a person is supposed to be able to do at that level. And this gives something that is measurable in a testable fashion.

So, the four levels I use with some typical verbs are

• Recognition (renamed: originally “knowledge”): recite, list, label, locate
• Comprehension: restate, give example, summarise
• Application: apply, solve, show
• Analysis (including Synthesis and Evaluation): compare, compose, invent, critique, evaluate, judge

Let me apply these levels to myself and some areas of knowledge just as examples.

So, do I know the Java memory model? Well, I follow along when my colleague Tommy talks about it, but I am not sure I could restate it without serious mistakes; so at recognition level yes, and perhaps at comprehension level, but not deeper.

Do I know Scrum, Java exceptions, or Domain Driven Design? Hey – how long do you want me to talk about it? I guess I could spend endless hours in discussion on those topics with other experts – so I would say analysis level knowledge.

Do I know JPA 2.0? Sure, I could solve a problem by using it, but I would probably fail when people start discussing trade-offs and what is happening “under the hood” in different implementation; in other words application level knowledge.

As a side note I would say the levels are logarithmical (like the Richter Scale), so that each level of depth takes ten times amount of thoughtful experience to reach, compared to the previous. You can learn a buzzword by listening to a “sales-level” presentation of one hour. To be able to restate it yourself, you probably need to spend a day (10 h). Before you can practice it without checking up details all the time, you probably need two-to-three weeks experience (100 h). And the level where you can compare and contrast different approaches will probably take half a year (1000 h). Of course it is the two latest levels that are most interesting and important to system developers.

Back to the bike riding: recognition would be “yeah – bikes are a kind of vehicle – I see one over there!”; comprehension would be “you get onto it, pedal to get speed, steer by pulling the handles, and break by pedalling backwards”; application would be: “let me show you – watch me!”.

And analysis level? Well, if you want to turn left you should not pull the left grip – that will cause you to tip over to the right due to the centrifugal force you expire when the bike starts turning left. In short – the bike will turn left, but you and your centre of gravity will continue forward; so you fall into the ground on the right hand side of the bike.

And, by the way: centrifugal forces do exist.

To actually turn left you first pull the right handle. The effect is that you start falling over to the left. After a split of a second you have fallen the appropriate amount so that your angle towards the ground will make gravity and centrifugal force balance for the turn you intended. Then, you pull the left handle to actually do the left turn. And as you now have the appropriate angle, forces balance out and you stay on top. People trying to explain this often express it as doing a small “contra-turn” in the opposite direction as a preparation before making the “real” turn.

If you want to see this in action, have a friend film you while just doing some cycling around on the backyard, and then watch it frame by frame. You will see that you intuitively do the right thing – but you probably had no idea you did.

Note that for most of us there is no need for analysis level knowledge on bicycling – we are perfectly happy to just be able to ride that bike. The analysis level knowledge of bike riding you find at people like motorcycle driving instructors or those that just have studied a little bit too much analytical mechanics.

The same goes with people in the system development field. Just doing stuff and gaining “experience” does not give analysis level knowledge. To there you also have to have an analytical process in place that constantly evaluates what you do, why you do it, and what the alternatives could be.

Culture that analytical process.

Most people do not know how to ride a bike – they simply do it.

Yours

Dan