Domain-Driven Design, part 1 — Language

Domain-driven design is a software design that focuses on understanding underlying business. It is useful for long-term projects because it leads to high-quality software that serves users. It helps when dealing with difficult problems, keeps track of core problems and prevents us from getting lost in the code.

Personal Motivation

Thanks to the domain design I started to learn how to think in object oriented programming. I know there is still much to learn, but at least I know in which way to progress. DDD has a huge positive impact on my architectural, modeling and testing skills.

This is just a side effect because domain-driven design is not about objects, domain-driven design is about the domain.


Domain Language



Language is crucial because customers and experts are telling their stories in their language. But it is also natural language, inaccurate, ambiguous, context-aware. And as we can see, language can be tricky even within one domain.

Ubiquitous Language

Is price that we are selling for always a selling price? Do users use often term selling price instead of price? Great, maybe experts agree that we use only the term selling price because it is definitive. When we discuss with users, we always use term selling price, the user interface communicate selling price, we find selling price in the documentation. What is written in code — variables, classes, methods? The selling price. Always.

The strict term became part of everyday users’ life, communication between experts and programmers, programmers’ work. The term is everywhere, it became ubiquitous.

Ubiquitous language connects users, domain experts, programmers, so it creates project backbone. It may not be a bad idea to document key terms, especially if terms have conditions of use. The documentation may help new programmers, as well as users, to get into the project.

Be careful, ubiquitous language, this definitive, specific language must always come from domain experts or users, their stories and their conversations. We must not invent our terms, our language. Never.

Impact on Model

VIP Price

We can think about clients use-case — we need another price. Well, what will happen when he asks for yet another price? We will have to rewrite our software again. What if we generalize this task? We can offer an unlimited amount of prices by introducing price lists. A product can have a price in multiple price lists. Sounds good, right? A cool feature — price lists.

Mental Model

We think about product, price lists, and prices

When the client tells us his stories, we have to map his language to our language and our model. When he is using software, he has to map his model to language in the user interface. We ended with two different languages and with models that diverged.

And now imagine that a client wants to lower the VIP price. For him it is straightforward — he wants to change a number that is called VIP price. What is it for a programmer? We have to find a VIP price list, find a price for a given product in the price list and finally change the value. What would happen if the price list is not found? If the price in price list is not found? Now we have use cases that do not exist in client’s domain. The client can’t explain what should happen because it does not make sense for him.

The model does not fit user use cases, the model language is messed up. If we would invent our language, we would speak with users in terms they do not understand, and they would be using their language anyway because it is their domain language. The user interface will not communicate with them in their language and using the software will cause frustration.

The domain way to solve diverged model and language is to refactor software, so user and programmer will use the same ubiquitous language.

Domain Evolution


So simple, yet so powerful.

Next time we’ll take a look at modeling.


FOWLER, Martin. UbiquitousLanguage. [online]. 2006 [2017–11–28]. Available:


Developer interested in Domain-Driven Design & Modeling

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store