One of.. no, the core concept of Domain Driven Design is the Ubiquitous Language. The UL, simply put, consist of the words and phrases we use to express the domain model. It is the language that both the domain experts and the team of developers use when talking about the application. The UL should exist anywhere the concepts of the domain is addressed – in written documents, diagrams, conversations - and in code, where classes and their methods should be named according to it.
That sounds fairly reasonable; some would even say obvious.
Do you speak-a my language?
However: Most developers write code in English, even if it is not their native tongue. For them, most of the domains they work with are thus expressed in a language which differs from the language they write code in. The question then becomes – should we translate the ubiquitous language into English? Or should we really be writing code in our native language? Or do we write code in English, but use non-English words and phrases where required to conform with the UL…
I’ve worked on projects where the ubiquitous language became anemic because the developers translated the Norwegian domain into English. Apart from often having trouble finding good translations for many of the domain concepts, the fact that the developers begun calling things by their English names when talking about them often caused misunderstandings between the developers and the domain experts.
The “GetLønnslipp()” method is a common joke amongst Norwegian developers – but maybe that actually is the way we should be naming our methods?
