Este post también está disponible en español.
Posts in this series:
Introduction
Architecture
Tactical patterns introduction
Value objects
Entities
Domain services
Modules
Factories
Aggregates
Repositories
Domain Events
Event Sourcing
Sagas and Process Managers
CQRS
Policies
Domain Driven Design or DDD is a software development philosophy created by Eric Evans in his book Domain-Driven Design: Tackling complexity in the heart of software (also known as the “blue book”).
It allows teams to handle effectively the construction and maintenance of software for complex problem domains.
By far the most common form of architecture present on business applications is the Big Ball of Mud (BBoM). This kind of architecture is defined as a haphazardly structured, sprawling, sloppy, duct‐tape‐and‐baling‐wire, spaghetti‐ code jungle.
Credit: GarryKillian image on Freepik
One of the main reasons that turns our code into the BBoM architecture is because the domain complexities (essential complexity) are mixed with technical complexities (accidental complexity).
Software projects often fail when the business domain is not understood well enough.
Aside from the no-functional requirements (performance, security, etc), the hard part is the creation of a model of the domain that can meet the business use cases.
Domain Driven Design makes developers and business experts work together building the software.
In addition, DDD allows the business to learn more about itself. No business expert usually knows everything about it. With DDD everyone learns because it creates a continuous discovery process.
Knowledge is centralized and everyone has access to it. It’s not compartmentalized on different areas or departments of the company or hidden in the source code.
There are no translation of terms between business experts, developers and the software. A shared language that everyone speaks is created.
DDD provide us with patterns to understand the domain and to build a software solution that is useful for solving problems within it.
DDD patterns are classified mainly in two groups:
- Strategic: Allow us to break down the domain and shape the architecture.
- Tactical: Allows us to create an effective model for complex domains. Many of these patterns have been around on the community and in books like Design Patterns: Elements of Reusable Object-Oriented Software (also known as the GoF) and Patterns of Enterprise Application Architecture.
Distill the problem domain
The domain is what an organization does and the world in which it does it.
Every organization has its own know-how and way of doing things. That knowledge and its particular methods to carry out its operations is what we know as the problem domain.
Its important to distill this domain in order to distinguish what is important and what is not. In large softwares not everything has to be perfectly designed, its a waste of time and costs.
Development teams and business experts distill large, complex domains together and break them down into smaller, more manageable subdomains.
For example, a business that sells products online might identity the following subdomains:
- Product catalog
- Purchase orders
- Billing
- Payments
- Product delivery
- Stock management and inventary
- Customer support
In order to discover and understand the entire domain, workshops and different practices are used such as:
A business contains a large amount of information, not all is useful to solve the problems we want to solve. This information needs to be distilled in order to build a model that is effective in solving business use cases. This activity is known as Knowledge Crunching.
Credit: Robert Laszczak
Decomposing the problem domain
Distillation reveals that the domain is composed of different subdomains. Not all are equally important to the business. All are essential for the entire system to function, but some are more valuable than others.
We don’t want to put the same effort and quality into the different parts of the system. This will lead us to lose focus on those areas that are essential for the business to grow and be competitive.
We can identity three types of subdomains:
Core Subdomains
These subdomains are the most important. They are the reason why we are building software instead of buying it.
Core subdomains give the business the main competitive advantage. It is where the business must excel.
What makes our e-commerce system different from the competition? Perhaps we have a very efficient delivery system that delivers products on the same day or perhaps our difference is on the user reviews.
We must put the greatest effort and the best programmers on this kind of subdomains.
Generic subdomains
These are subdomains that are usually present in several businesses and systems. For example, an email sending service, reports, billing, etc.
These subdomains don’t have any specialization but are common problems of several companies.
Although they aren’t core to the business, they are necessary for the operation of the company.
It doesn’t make much sense to invest a lot of effort in these subdomains because they won’t give us a competitive advantage. We can try to buy software or develop solutions with less focus and with junior developers.
Supporting subdomains
These subdomains are not core but they are not generic solutions either. They are problems in which the company has some kind of specialization in comparison to other companies.
For example, the inventory system is not core but nevertheless it has many peculiarities compared to how other companies do it.
In this kind of subdomains we also don’t want to invest a lot of effort. Look for existent solutions that can be customized.
Sometimes we can solve these problems without needing to build a software. Instead we can use manual processes freeing up developers to work on the core subdomains.
Build effective models
To solve problems with software, we must first start talking about the models of the domain that we are going to create. Models that we will later represent in software.
Instead of building a big model of our entire problem domain (which would lead us to have a very complex model), we’ll make a model for each subdomain.
A model is an abstraction that we create to satisfy business requirements.
To avoid accidental complexity, we isolate our models from technical and infrastructure aspects.
Not all models are created equal. The most appropriate design patterns are chosen according to the complexity and needs of each subdomain. Generic or supporting models may not need a rich object-oriented design and may have a more procedural or data-driven architecture.
A common mistake is to model the reality. A model is a useful abstraction designed for our particular context. A geographic or political map are two models with completely different purposes. They are abstractions, not the reality of the terrain.
A model must include aspects that help us solve business problems and must avoid irrelevant details.
If we look at the London subway map, this model is designed to show the different stations and combinations. But this model doesn’t show real distances. Its purpose is to help us know which subway to take and be able to reach our destination, not to accurately show at a geographical level how far one station is from another.
Summarizing:
- Businesses are usually large and complex, do not try to model everything.
- Models must be useful abstractions and must be constantly refined.
- Don’t model all the relationships that exists between concepts in real life.
Another issue that we must be careful about is the use of abstractions. When we model concepts using objects we are surely going to design concrete object and also abstract ones.
We must be careful with the use of abstractions, they always have a price and therefor must be limited.
It is better to be explicit and repeat yourself than to try to put together loosely unrelated concepts or hide an important business concept under layers of abstractions.
Ubiquitous language
The true value of DDD resides in the collaboration between developers and business experts to produce a better understanding of the business.
To reach a good understanding you must be able to communicate effectively. This is achieved by creating a shared language that everyone speaks, using the same terms without the need for translations. This language is called ubiquitous language.
The creation of a ubiquitous language allows teams organize the mental model and the code easily. It gives clarity and consistency.
The language must use business concepts and is expressed everywhere: conversations, diagrams, documentation and source code.
Due to the rigor required when programming, many times new concepts are discovered that must be incorporated into the ubiquitous language. These concepts are discussed together with business people and new definitions are agreed upon to disambiguate. A ubiquitous language is constantly evolving, terms are refined and new ones are incorporated.
This aspect of DDD is key for developers and business experts to collaboratively create and evolve a model.
The model expressed in software using this language allows anyone to clearly understand the business processes, the concepts and how they relate to each other. If, for example, we are building a software for the accounting domain, anyone who reads the source code would learn about accounting.
Next post
In this post we discussed the importance of being able to understand well our problem domain and break it down into less complex subdomains. We also discussed how to categorize these subdomains in order to understand where to focus our efforts, we also talked about having one model per subdomain (which we’ll later represent in software) and the importance of having this model expressed in a ubiquitous language that developers and business experts can evolve together.
In the next post of this series we are going to talk about how to protect the integrity of our models so that they don’t contaminate each other (something that would inevitably will increase the complexity again). We are going to introduce the concept of Bounded Contexts.