Programming and Ubiquitous Language (DDD) in a non-English domain

Question

I know there are some questions already here that are closely related to this subject but none of them take Ubiquitous Language as the starting point so I think that justifies this question.

For those who don't know: Ubiquitous Language is the concept of defining a (both spoken and written) language that is equally used across developers and domain experts to avoid inconsistencies and miscommunication due to translation problems and misunderstanding. You will see the same terminology show up in code, conversations between any team member, functional specs and whatnot.

So, what I was wondering about is how to deal with Ubiquitous Language in non-English domains.

Personally, I strongly favor writing programming code in English completely, including comments but ofcourse excluding constants and resources.

However, in a non-English domain, I'm forced to make a decision either to:

1. Write code reflecting the Ubiquitous Language in the natural language of the domain.
2. Translate the Ubiquitous Language to English and stop communicating in the natural language of the domain.
3. Define a table that defines how the Ubiquitous Language translates to English.

Here are some of my thoughts based on these options:

1) I have a strong aversion against mixed-language code, that is coding using type/member/variable names etc. that are non-English. Most programming languages 'breathe' English to a large extent and most of the technical literature, design pattern names etc. are in English as well. Therefore, in most cases there's just no way of writing code entirely in a non-English language so you end up with mixed languages anyway.

2) This will force the domain experts to start thinking and talking in the English equivalent of the UL, something that will probably not come naturally to them and therefore hinders communication significantly.

3) In this case, the developers communicate with the domain experts in their native language while the developers communicate with each other in English and most importantly, they write code using the English translation of the UL.

I'm sure I don't want to go for the first option and I think option 3 is much better than option 2. What do you think? Am I missing other options?

UPDATE

Today, about year later, having dealt with this issue on a daily basis, I have to say that option 3 has worked out pretty well for me.

It wasn't as tedious as I initially feared and translating in real time while talking to the client wasn't a problem either.

I also found the following advantages to be true, based on my experience.

• Translating the UL makes you pay more attention to defining the UL and even the domain itself, especially when you don't know how to translate a term and you have to start looking through dictionaries etc. This has even caused me to reconsider domain modeling decisions a few times.
• It helps you make your knowledge of the English language more profound.
• Obviously, your code is much more pleasant to look at instead of being a mind boggling obscenity.

Answer 1

I've faced this issue often, and in my opinion the answer is: "there is no single answer valid for all of the scenarios."

But keep in mind that Ubiquitous Language is not a goal per se. It's a tool to reinforce communication among the team and the Domain Experts and to enforce conceptual coherence of the implemented model in code, tests and conversation.

If you can speak UL unambiguously you're on the right path. If you and your peers are continuously translating from code to conversation or from concept to concept, then you're probably off track.

In practice, not all domains are equal, nor domain experts. Some domain have a lot of English terminology anyway (tech-driven domains, for example) and it sounds reasonable to opt for a full-English choice. However, some cultures might influence this choice (French comes to mind) and diffusion of English terminology varies from country to country. In some other domains (Legal, to name one) there's no way to translate some terms. Or translating would make it absolutely harder for Domain Expert to follow the conversation.

In general, we are more interested in what the Domain Expert has to say. So we want to make things easy for them. Otherwise they could just take a UML class and read our diagrams (that was a joke). So the only real recommendation here is: "pay attention to the Domain Expert behavior", if they're engaged in the conversation and the conversation goes on smoothly, you're probably on track, keep that language. It might cause a little extra work on the team, but that's fine. As developers we are somewhat trained to learn words with specific meaning in a context.

Strangely, this question always is accompanied by the assumption that all the code needs to speak one language. That might be challenged too. I am not a native English, and knowledge of a foreign language is not flat: my brain goes fast when talking about name, surname, car and the like, misses some details when talking about zipcode, slows down when talking about loan and definitely asks for a reassuring explanation when talking about mortgage.

So, again, choose the best combination that will make the key conversation flow and provide the highest amount of information and feedback from the Domain Expert.

Answer 2

I recently worked on a DDD project in Switzerland, were the domain was taxes (specifically VAT and another kind of tax... that is not easily translatable to English...).

They chose the first option: UL in German, used in the code in German as well.

Before I worked on this project, I had exactly the same aversion as you for mixed language code. I (still) like to have everything in English, although I am not a native English speaker. I am also not a native German speaker. So when I started to explore the codebase, I was horrified.

After a year working on that project, I must admit that I think it was the right decision in this case (we could also have used French or Italian, the other official Swiss languages, but the majority of the actors in the project were native German speakers).

Many of the specific terms of the domain were really not translatable to English in a meaningful way. I had to learn the German terms anyway to communicate with the rest of the team. It would have been messier to have to also learn English translations, that would have been invented out of thin air anyway.

So I guess it really depends on the domain. Some domains will be really difficult to translate to English and it will not make much sense.

It probably depends on the native language as well. German is a language were you can compose words in roughly the same way and especially the same order as in English. For example a tax declaration would be a Steuerdeklaration. Not shockingly different.

I don't know how I would make an equivalent class name in French, for example, were the natural term woud be "déclaration d'impôts", with the opposite order and an extra preposition in the middle... And that is just a simple example. I would be really interested if anybody has experience with that kind of naming in latin languages (French, Spanish, Italian, Portuguese...)!

Another challenge was the plural forms, which in German are sometimes hardly distinguishable from the singular (whereas in English it almost always has an s at the end).

The accentuated characters were OK, since in German they all have a non accentuated equivalent ( ü -> ue and so on). It is another point where the French would be more problematic...

Answer 3

I usually regard certain technical words as language neutral even if there is a translation in the other language.

For example when talking about coding in German I still use the English technical vocabulary as if they were German words even if there is a German equivalent.

In your case I'd do the opposite. Import certain technical words from your native language into English just like foreign words have been imported for centuries. Make them grammatically behave like English words. It feels strange at first, but you'll get used to it.

Answer 4

I agree with the Most programming languages 'breathe' English comment, that always becomes an issue with multi-language development efforts

Normally I would have the UL in the language of your programming team

What we have done in the past is to make up new words that better express the domain topics. With a French/English project the made up words where mostly English based but with french flavour (not too hard as many English words are French anyway), but this could apply to any language mix

e.g.

"quantity bois"

In English is "Amount of wood" or "quantity of wood", in French is "quantité de bois", so is close enough for both speakers. This should reduce the amount of new words each speaker has to learn

How big is your domain UL? This becomes the problem. If it less than 100 key phrases then you can use a hybrid made up style language, if larger I would stick the the predominant language of the developers as they usually have to deal with it more intensely

Publish a wiki dictionary/thesaurus for everyone to reference too as required so there are no excuses for comprehension