Developing high-quality software products requires a good strategy. There is no room for fortuity or reading the tea leaves. Domain-driven design can be a possible solution that helps map out a development path and provide good practices in the process. This article gives an overview of this concept, including the important advantages of using DDD, and highlights the possible challenges connected with the topic.
What is domain-driven design?
Domain-driven design (DDD) is an approach to software development focusing on the area that the product references or operates within as the center of every action taken. Everything started in 2003, when Eric Evans published his book, ”Domain-Driven Design: Tackling Complexity in the Heart of Software”, in which he described this approach and related patterns.
It is impossible to talk about domain-driven design without describing the term ‘domain’. Domain in development is the predefined field in which the application will be operating. According to Eric Evans, a domain is a “sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software.” Based on the domain, developers create a domain model: abstractions describing domain aspects that can be used to solve related problems.
The most important goals in domain-driven development are:
- keeping the domain as the primary focus during project development,
- using a domain model as the project base,
- cooperation across teams.
The DDD approach focuses on combining the business and technical components and sets a clear path for them.
Important terms in domain-driven design
DDD key definitions also include the domain model described above. This short glossary aims to clarify the topic, which can sound a bit complex with its new terminology. Descriptions are according to E. Evans.
- Aggregates are the main modeling unit in DDD. They can be described as clusters of domain objects that can be treated as single entities.
- Bounded context is a subsystem within which a specific model is described and relevant. Bounded context depicts the problem in a detailed way. Everything must mirror it, as one of the aims of DDD is to build a product that answers a predefined problem.
- Context is the environment in which a word/expression appears and specifies its meaning.
- Context Map is a tool that helps better understand the relations between bounded contexts. They often have a graphic representation.
- Domain logic is the "business logic" of the whole project, a set of rules that influences design storage and process development.
- Entities (also known also as Reference Objects) are identifiable objects whose identity is unchanging over time. These objects can be compared with each other when the attributes do not form the object's identity.
- A Model is a system of abstractions that defines selected parts of a domain and can solve problems connected to it.
- Ubiquitous language refers to the terminology and terms used in every part of the design and development process by all specialists engaged in the project. A ubiquitous language is related (more or less) to the domain model.
- Value objects primarily define an aspect of the domain. An object's attributes, not its identity, are the most important. How do value objects differ from entities? Objects without their unique identification are easier to maintain. In most cases, there is no need to change a value object. Besides, the lack of identity might be used to simplify and optimize the Domain Model.
These are the most common and popular terms connected with the domain-driven approach, however they are only a drop in the ocean of DDD phrases.
When to use Domain-Driven Design?
The answer is very simple – whenever achieving the business goal is crucial.
Developing software that provides actual business value is not the same as designing typical business software. In the DDD approach, software is about business, less about technology itself – designing software as close as possible to what the stakeholders and specialists would build if they were the software developers.
DDD helps make the whole design process consistent and simplifies more complex issues to collapse the technical and business aspects of the process. Implementing a domain-driven design approach also positively impacts the clarity of communication between the technical team and less-technical persons involved in the process (e.g. stakeholders).
Check out how the kick-off meeting can also help your team better understand the project's business requirements.
Why use DDD? How domain-driven design helps
The main advantage of domain-driven design is the fact that it facilitates focusing on delivering business value during the development process. How else does DDD help?
DDD provides a valuable model to the business – coworkers engaged in the project, like domain experts and software developers, work together to design software that reflects the idea of the business professionals.
Due to its concentration on delivering the application’s business relevance, domain-driven design aims to achieve service-oriented or business-driven architecture above team roles and provides a system to prevent software or project failure by recognizing and reacting early to failure symptoms.
The DDD approach fulfills the technical software needs with the help of tactical design modeling tools – they allow developers to produce software that correctly represents the domain experts’ mental model and at the same time, is testable and scalable.
Below are the potential benefits of DDD for your company:
- More effective communication between team workers regardless of their role in the project or their knowledge of programming, thanks to the ubiquitous language that is composed by every team member and has to be approved by the whole group engaged in the project.
- The business goal takes center stage – domain-driven design is business-oriented, which helps in creating a product that meets the company’s requirements.
- DDD facilitates staying on a predefined (both business and software) path. The roles in the team are clearly defined, and the project goal is settled at the very beginning, which makes the whole development process more efficient.
- Because of the layered design, updating or modifying the product is not a problem anymore.
Layered design in DDD
DDD offers a new term: layered design. What is layered design and why is it attention-worthy?
Layered design applies to more complex projects which need to be systematized and require a clear architecture. The domain-driven design approach recommends using layered architecture to manage the overall project better. Evans cited four layers:
- User Interface Layer (Presentation Layer) – shows information and/or data to end-users and receives and interprets their input and actions.
- Application Layer – defines the software's jobs and directs the domain objects to work out problems. This layer is significant from the business perspective and can be required to interact with the application layers of other systems.
- Infrastructure layer – sustains communication between the other layers and external services or resources, and manages storage and data access.
- Domain layer – the last-mentioned layer, but definitely the most important. The project might not require all of the layers mentioned above, however the domain layer is always necessary. It includes the business logic, information about the domain, and the system's current configuration.
This approach can require many changes in a company’s development process. How can you introduce DDD smoothly into your business? The following section should make this small revolution easier.
How to implement data-driven design?
The domain experts are necessary to successfully specify the business domain, and they can help make the DDD strategic phases smoother. Using DDD requires taking the time and effort to consider aspects like business domain, research concepts, and terminology that must be discussed with domain experts.
Nevertheless, applying DDD comprehensively, with value to the business, will be more time-consuming.
Possible ways to establish a domain model:
- Strategic Modelling – also known as strategic design. The primary goal of the domain experts and the technical team is to specify the Bounded Contexts, the Ubiquitous Language, and the Context Maps.
- As a rule, Tactical Modelling (tactical design) is more complex than strategic modelling. Tactical design uses Entities, Aggregates, and Value Objects, among others.
However, every choice should be made with a focus on the domain model. This is why it is good to have a domain expert on the project who supports the process with experience-based advice.
DDD is not a solution for everyone – keep reading to find out when domain-driven design might not be right for you and your team.
DDD challenges – the disadvantages of domain-driven design
“Use DDD to model a complex domain in the simplest possible way. Never use DDD to make your solution more complex.” This quote from Implementing Domain-Driven Design by Vaughn Vernon should be a key criteria when considering implementation of DDD.
Domain-driven design is adjusted to solving complex problems, and it can be "too much" for simpler, or not strictly business-oriented, projects. To successfully implement the DDD approach, the company needs domain experts who understand the exact characteristics of the subject area. Sometimes, several team members need to thoroughly know the domain to incorporate it into the development team’s approach. Finally, a domain-driven approach works best for complex business ideas, but not necessarily for highly technical ones. Applications with significant technical complexity can be demanding for business-oriented domain experts. That can result in problems with matching the right strategy to the project.
To sum up, DDD’s challenges are:
- Suitable mainly for more complex projects.
- Require significant expert knowledge.
- A poor fit for highly technical projects.
However, it is also good to have a risk management plan – read the previous article to get more details about risk management in software development projects.
Conclusion
The domain-driven design approach allows the development team to take a big picture view of the project. It helps coordinate software development and business requirements to create a holistic and complete product without compromising its quality. It also provides solutions to the management of more complex projects – e.g. layered design. As always, there is no one-size-fits-all solution, and DDD is no different. When you are developing a simple and non-complex project, there is probably no need to implement an approach that is oriented toward solving multi-faceted problems.
