Presenting on Ubiquitous Language at Jfokus 2011

Dear Junior

I have gotten the delighting message from the Jfokus committee that they want me to speak at the Jfokus 2011 conference in Stockholm in February. I had proposed a presentation on the Domain Driven Design concept of Ubiquitous Language which they have accepted. 

It seems to me that the ubiquitous language is one of the hardest things to get right. When I look at my own experience it is a part where there are a lot of small distinction, distinctions that are subtle but make a huge difference.

Just take an example of how you can express the same thing in different ways that seem synonymous, but actually make a huge difference.

Compare

"An account has a phone number. The account can change phone numbers."

with

"An account has a phone number. The phone number can be changed."

The difference might be subtle, but in a precise language the distinction is important. In the first case, the account have still the same (conceptual) phone number, which has been edited. The account and the phone number are both entities. In the second case, the account have changed its phone number to another phone number. In code the two cases would be

1. account.number.changeto(numbersequence)

2. account.number = new PhoneNumber(numbersequence)

So, what difference does it makes?

Well, somewhere else we might require that a new account might have the same number as an old account. Fair enough. But what happens if the old account gets a new number? Does the new account change its number as well?

Have we taken the pain to actually create a strict language that is understood in common, then we have the answer in the language. If we do not have that strict language, chances are high that we arbitrarily select one of them that "feels right at the moment". However, next time a similar situation arises there is no guarantee that what we pick arbitrarily that time is logically consistent with the first pick. Over time we risk getting a system that behaves subtly, or obviously, inconsistent with itself.

Of course, this is just one example. In the presentation, what I want to cover are practical aspects of to make a shared language to become useful - and what it takes to become useful. E g it has to be both rich enough to express the complexity of the problem, but it must still be precise enough so we can use it as a base to build a system.

Other aspects I want to cover is how such a language can grow over time (not a Big Upfront Design), problems and traps when introducing a new term, and the challenges of "mixed language environment" such as when there are both Swedish and English around.

Of course you recognize several of these subjects as we have discussed these earlier. However, I hope to put them together in a concise and structured format - and want to roll in some new ideas. I am sure there will be plenty of reasons to return to these areas in subsequent letter.

Yours

   Dan

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.

Traps When Establishing a Domain Term

Dear Junior

Establishing a domain term like “username” is not simple. Taking Domain Driven Design seriously, we then need to make sure to end up with a meaning of the word that is both commonly accepted and precise. What we really are up to is to make “username” a part of the ubiquitous language talking about this system. There are several traps to avoid here, where three are extra risky.

The first trap is to become too techie – talking among the programmers, agreeing on some meaning, and settling for that. Problem is that the term never become ubiquitous, thus rendering it useless as soon as we want to communicate with people outside the tech clique.

Instead we need to involve all the people: programmers, DBAs, product owner, GUI designers, tech writers, and trainers. Why? Because we want (need) the same term being used with the same meaning in code, manual, training material, and GUI.

Second trap is to talk about usernames in general. It is completely fruitless and uninteresting to discuss the “true nature” of usernames or to find a definition that applies to a lot of systems.

Instead, what is useful for us is some definition of what a username is in this specific system. We should not pretend, not even strive for, that our definition of “username” will apply to some other system – our definition is bounded by the context of “this system at hand”.

Third trap is not being techie enough – settling for vague definitions. It is not enough to agree that the username is “some kind of identifier string”¨ - simply because that definition is not useful. What we need is something that can be turned into data structures, search schemes and validation code.

Instead, we need the courage to nail down a definition that is precise – and precise in the mathematical, logical sense. Here the bounded context comes to our help. The “weakness” that our definition only applies to our system turns into a strength; we can be very precise about our needs and need not take the rest of the world into account. Close each discussion with stating something along the line “so, in our system we define usernames to be strings of characters that are at least five characters long, maximum 25 chars, and consists solely of lowercase letters”.

So, if we end up with a definition of “username” that is shared and agreed ubiquitously among all involved, that applies specifically bounded to the context of our system, and that is so precise we can use it for coding – then we have established a term that has become a part of our ubiquitous language.

Yours

Dan

PS Of course, establishing ubiquitous, context-bounded, and precise definitions is crucial for security.

Avoid Synonyms in the Ubiquoutous Language

Dear Junior

When walking the round trying to establish a new term in the ubiquitous language of a system, it is very tempting to start accepting synonyms.

Perhaps we tried to make 'username' explicit in the model. We then need to settle what a username is, and how it is checked against its validation rules. Among the programmers, we have used “username”. When we get over to the GUI designers they tend to talk about it as the “handle”. Later on we find out that the tech writers dig the term “alias”, and that is what they have used in the manual. It might seem tempting to say “we all mean the same thing, so lets accept these as synonyms” where after we write three entries in our glossary

“username, …”,

”handle, see username”, and

alias, see username”.

So, is that so bad? I guess we can handle three words meaning the same thing. Well, the problem is not the single words, it is the language and in the combinatorial explosion.

We also need to define what we call when we control that a username fulfils the formatting rules. It turns out that we preferred “validate”, however those that were on the Gazunga project (disregarding department) seem to prefer “checkup”. Let us accept these as well and add to our glossary

“validate …”, and

“checkup, see validate”.

Even if each word have a very limited number of synonyms, we now have lots of synonyms for phrases (remember that when a glossary is about words, the ubiquitous language is about phrases). There are six synonym prhases for “validate username”.

1. “validate username”
2. “validate alias”
3. “checkup handle”
4. “validate handle”
5. “checkup alias”
6. “checkup username”

Further on, the user account are by some referred to as “pref-set” (preference setting space), and by some as “area” (as in private work area). So, now there are no less that eighteen ways to phrase “validate the username of the account”.

Et cetera, you get it.

So, letting synonyms into the ubiquitous language quickly leads to having not one language, but a lot of dialects that quickly drift apart to form separate languages – and the ubiquity is gone.

Of course there are occations when you have to accept synonyms. If there is an established terminology outside the project there is a point in adhereing to it – but what to do if there are several competing standards. For example, the finance department might want to use the accepted term “imbursement”, but the marketers insist that the established term in our customer base is “money-forward” – both fully acceptable external bodies. In these rare cases we have to accept synonyms, but I still advice to denote either of them as the primary term, and only use the other when necessary. In the glossary it might say “money-forward (aka imbursement), a payment made by … in exchange for… (imbursement preferred by finance department)”.

By all means, do use synonyms when they are absolutely necessary, but be very restricted. I promise, if you allow synonyms at an early stage, then confusion will arise somewhere down the road.

Yours

Dan

ps When trying to avoid synonyms you in many ways have the same mind-set as when establishing a canonical data format in the model - but you work in slightly different areas.