The first question that comes to mind when considering domain driven design is: What the hell is a domain? The term refers to a specific area of knowledge or experience, and can be used to refer both to real-world scenarios as well as abstract concepts. In short – anything you work with. Anything you want to model effectively. In this article I will focus on how it could be applied to software development projects.
The concept of domain driven design has been around for some time now but still lacks mainstream attention among developers. In this article I will try my best to describe what it is and how it can be applied to software development. I will also give you a few tips on where to learn more about the subject, because although the concepts are simple enough, things get more complicated when you start digging into code.
I like analogies and this article includes lots of examples – hopefully making things stick in your mind better than dry definitions would. When I’m unsure of something, I try to arrive at understanding by comparing it with other things that I am familiar with. If you’re new to domain driven design, maybe you’ll find some interesting similarities between it and some real world concepts which you deal with every day (like parking your car or talking to people).
Once we have some common grounds we can start looking into the key tenets of domain driven design and how it can be implemented in software.
What the term “domain” is?
The term “domain” refers to a specific area of knowledge or experience, and therefore could refer both to real world scenarios as well as abstract concepts. In short: anything you work with. Anything you want to model effectively.
The core idea in domain driven design (DDD) is that instead of trying to create an abstract solution that can accommodate all possible future requirements, we should focus on adapting the problem space itself to the language and models provided by the domain.
A real world example might help at this point: Let’s say you need to store your records in a database. For simplicity let’s only consider unstructured text fields. You could come up with dozens of different field types like title, description, content etc., each designed for a specific use case – but when it comes time to actually build your application, implementing these designs will be akin to reinventing the wheel over and over again.
There are better ways. Think about how people organize their documents. The term “domain” refers to a specific area of knowledge or experience, and therefore could refer both to real world scenarios as well as abstract concepts. In short: anything you work with. Anything you want to model effectively.
In terms of software development we will focus on applying this concept when we need to create complex systems that handle large amounts of data – such as enterprise applications. These kinds of projects often become unwieldy because they tend to deal with numerous entities (e.g., customers, products, orders) all connected together in different ways (e.g., billing rules, discounts). The sheer complexity of these systems makes them hard to model and easy to get wrong.
Enter – domain driven design!
Want a quick breakdown? Here it is
Create a shared, ubiquitous language that everyone can understand.
Focus on real world scenarios that you have to deal with every day.
Model the business from your unique perspective as a developer, understanding both its passive and active aspects.
Ensure flexibility by designing for the unknown future of the domain. In other words: if you’re building an application for a company whose business may change in ten years time – how can you design one system that will allow new types of data and applications to be added without changing already existing ones? That’s why we need “ubiquitous language”. It must be shared (i.e., everybody has to speak it) and common (i.e., every developer must understand it).
Forgetting for a moment that you’re dealing with an application , think about other real world scenarios where this concept is used.
Healthcare
Doctors will often use medical jargon among themselves but need to be able to work with patients who don’t speak or understand the same language – therefore they must create their own “ubiquitous languages” which are specific both to their speciality as well as their patients’ understanding capabilities.
Law enforcement
Police forces not only deal with different legal systems all around the planet, they also have unique acronyms that mean something entirely different in each country. To combat this problem they have created a specialized language that everybody involved in the investigation can understand. It’s called “police lingo” and it is used both for written communication as well as code words used during arrests, interrogations etc.
Education
Teachers use an entirely different language with their students than they would normally speak to each other because children are less experienced with certain concepts – e.g., “hypothetical”, “proportionally” or “agnostic”. Furthermore, special care must be taken when explaining things which are considered sacred by some cultures (e.g., religions). And again: this language is not only spoken but also taught through books, lectures etc.
