Why Explore DDD
Domain-Driven Design (DDD) jargon can be daunting. Aggregate roots? Bounded context? This essay explains why DDD works without jargon so you can take that one step in exploring the topic more.
Imagine that you’re designing a REST API that returns a date. Knowing that dates are not a primitive type, you must decide how to represent the date in a string. You came up with these options:
Use ISO 8601: 2020-01-12
Create a custom date format: 20201201
Use business-friendly date: Sun, 12 Jan 2020
Most designers would immediately choose to use ISO 8601. It’s a standard, of course, we should use it. Why though? Why is using a standard a good idea? There are two essential benefits, and I would expand on this slowly, weaving the benefits back into DDD.
One of the benefits of using a standard is they don’t change frequently. Subsequently, when you design a part of software against what’s hard to change (like ISO 8601), this part of the software will change less frequently. This is important because making change cheap, or in this case, reducing the need for change, is the core responsibility of a software designer.
Think about it, a door knob is designed that way because we have hands, which hardly change. If a door is designed only to open based on what colour of clothes we wear, we have to change the door frequently (unless all your available clothes are the same colour!).
Unfortunately, not all things have standards. This, however, doesn’t break this line of reasoning. The question then is, what is the best alternative to a standard that we can use? The answer is language.
Ian Mortimer, a British historian and a writer of historical fiction, wrote the book The Outcasts of Time. The protagonist in the book time travels 99 years every day of their waking. Whenever they make a hop of 99 years, they can still communicate with other human beings.
Language changes are gradual, slow, and small, and these characteristics are what a standard like ISO standards would provide. The protagonists in The Outcasts of Time later discover that a new word has been introduced: mister. This new word is slightly adjusted from the word master, a small change. This new word was introduced in the 15th century and is still used today, a slow change.
Language, therefore, is a great concept we can use to design software. The realisation most software engineers face when they come to this understanding is this: part of their work is designing, and they’re surprised that these designs don’t come for free. You need to make an effort to design, and there’s no shortcut.
Of course, using the ISO standards is easier because someone has created the model for us. No effort is needed there, and it’s similar to your home. When you get new clothes, you know where to place them. When you get a new mug, you know where to put it. An interior designer has designed your home. Therefore, it’s easy to decide what goes where, and your home is easy to navigate.
A software engineer with this new understanding would realise they’re in a messy cave. There is no separation of rooms designed, and you are the one who has to make an effort to draw up those separations.
The language you must spend effort understanding and designing against are the languages used in the business. A business is usually run to solve a specific problem, so its language will be pretty specific for the problem domain at hand. You will be designing against this domain language.
You shouldn’t assume that the business people you talk to have a domain language or model, or standard in their head. The business people might say they’d like a room where they can sleep peacefully, and then you’re the one who’s responsible for naming it a bedroom. Suddenly, you have a domain model based on a domain language. It sounds simple, but it’s not as effortless as it sounds.
It’s worth noting that the design effort may get more challenging when inheriting a language from application frameworks. Most application frameworks don’t speak in any specific domain because, to be reusable, they have to be generic. When you use the application framework’s language, you become the translator of the application framework and the business domain language.
You have to choose to either spend time designing or translating. It may be tempting to be a translator because of the challenge you’d get in designing, but being a translator is also not without challenges. Note that there are cases where translating can be cheaper, but that’s beyond the scope of this essay. Let’s move back to the next benefit of a standard and go deeper into its next valuable property.
Having a standard implies one single meaning, and this property is beneficial for software design as it reduces miscommunications. Using ISO 8601, for example, 2020-01-12 will always mean 12 January 2020, not 1 December 2020. You no longer spend time checking what 2020-01-12 means. A shared meaning helps us communicate better, whether verbally or in code.
However, a standard takes effort and time to create. Therefore, the more practical option would be leveraging the business domain language.
The difference between a domain language and a standard is their scope. A standard may be applied internationally, but a domain language can only be used locally in the business. This difference is acceptable because we don’t need a globally common language to solve a local problem. A door knob works well for us humans, and it’s okay for them not to work for dogs.
When software is designed against a domain language, that software becomes self-evident. A self-evident design removes explanation. A self-evident design reduces the amount of psychic energy we spend understanding it because you’ll communicate in the same language everywhere, including your code.
Pay attention the next time you land on a well-designed website. You don’t have to read many of their texts. By scanning its content, you can understand what the website is about. This is the same for the codebase, documentation, or any technical artefacts you produce when they’re self-evident. When you speak in domain language and design against it, your artefacts will be easier to comprehend. This ease of comprehension, of course, assumes you understand the business problem, and you should.
So far, we conclude that it’s generally a good idea to design software against a domain language. Language changes are gradual, and language creates self-evident design. However, like any decision you make, this choice is not without a trade-off. There are many challenges that you’ll face when you adopt this approach.
For example, we previously mentioned how the date format 2020-01-12 has only one meaning in ISO 8601. A word within a domain language, though, can have multiple meanings. Taking an example from the retail industry, the word stock can mean the noun inventory or the verb filling the store shelves. This becomes a challenge. How should we tackle this challenge?
DDD will talk about Bounded Context to tackle this challenge. And this use of jargon implies that this is a good time for me to pause. DDD follows the reasoning in this essay deeply and thoroughly, containing patterns you can draw to solve your problem. I hope you’ll choose to explore more about this topic. Good luck.
Thanks to Márton Vető, who encouraged me to write this explanation up after I gave it in our coaching session.