What Is Domain-Driven Design? Meaning, Process, and Examples
Domain-driven design is first informed by business requirements so that programs are unique to the specific industry.
Domain-driven design is defined as an approach to software design and development that is first informed by business requirements, such that the program’s components (objects, classes, arrays, etc.) are all indicative of the specific industry, sector, or domain in which the business operates. This article explains the domain-driven design process, its key components, and best practices.
Table of Contents
What Is Domain-Driven Design?
Domain-driven design is an approach to software design and development that is first informed by business requirements. The program’s components (objects, classes, arrays, etc.) indicate the industry, sector, or domain in which the business operates.
Domain-driven design (abbreviated as DDD) is a method of software design that creates software according to the domain inputs inserted by the domain experts. A domain refers to the characteristics of the problem which the proposed software is to solve.
This means that the software would be specifically designed according to the characteristics of the problem to solve it. For this to be achieved, the structure and language of the software code used should match the business domain. This method also uses various principles and patterns to close the gap between business reality and software code. Domain-driven design is most helpful in solving domain complexities as it works to maintain the project’s primary focus as the core domain.
Domain-driven design and microservices
Just like domain-derived design, microservices are functions that solve business problems. However, microservices are written in bounded contexts, meaning they only solve a narrow range of issues. Developers can implement DDD in the architectural design of a microservice to help it attain its goal in its location. It works with microseconds in two different phases:
Phase 1: Strategic phase
In this phase, the developers get to know all the business requirements. They work with business analysts, domain experts, and company owners to understand all the needs and build a suitable model. They also learn about the relationships between the bounded contexts of the microservices. They can potentially identify four relationships in a microservice, they include;
- Open host service
- Published language
- Anticorruption layer
- Separate ways
Phase 2: Tactical phase
This phase entails the developers building detailed models. These models are technology-agnostic as their major building blocks are entities, value objects, aggregates, domain events, repositories, domain services, etc.
See More: What Is Version Control? Meaning, Tools, and Advantages
Important terminologies in domain-driven design
To understand the meaning of the domain-driven design, you need to understand the following seven concepts:
1. Domain logic/business logic
This term refers to the part of the domain that implements real-world business rules. That is to say, domain logic determines how certain data is to be stored, accessed, manipulated, or created according to the stated business rules.
For example, a real-life business rule states that the business must welcome every new customer/visitor. The business/domain logic dictates the routes and methods various business objects would employ to implement this rule.
2. Domain model
Individually, domain and model have their meanings in domain-driven design. Domain refers to the details of the problem you want to solve. The knowledge about the business, how it operates, its terminologies, rules, goals, and objectives. By knowing all this, the problem is defined.
On the other hand, a model is a simplified version of the solution for this problem. The model only focuses on the essential parts of the solution. That being said, a domain model is a structured and organized understanding of the problem the software is to solve. As the model part of this structure helps to focus on the essential aspects, and the domain part brings in both technical and non-technical details of the problem, there would be an explainable relationship between various entities in the business and how they should relate to solving the problem.
The domain model can be a written document, a diagram, or code examples. Whatever form it is, it should be able to serve as an easily understandable language between the technical and non-technical aspects of the business problem.
3. Subdomain
As stated earlier, the domain refers to the problem we intend to solve in all its details. However, the details of the problem can make the problem complex if viewed as one. That is why we have subdomains of the domain.
These subdomains would reduce the complexity of the company’s problem and make it easier for experts to focus on their respective aspects. That being said, there are three types of subdomains in domain-driven design.
- Core/basic subdomains: These subdomains are the most critical aspects of the company. These are the characteristics of the company that make it unique.
- Supporting subdomains: These subdomains support the domain to complete it. Without them, the domain would be non-functional.
- Generic subdomains: These are ready-made solutions that do not bring any specific rule to the business.
4. Design patterns
This entails reusing code patterns that were designed using an object-oriented language. These patterns would help you break through the problem’s initial elements to reach a clear solution.
5. Bounded context
There are different departments in a company, and some might have terms that have different meanings. For example, in banking, an account can mean a transaction account, bank account, etc., but it would mean a login account in e-commerce.
To prevent this confusion, developers can divide the domain into bounded contexts. The difference between these contexts and subdomains is that subdomains are divisions of the domain in a problem space. Bounded contexts are divisions of the domains in a solution space. In other words, bounded contexts are implementations of the subdomains.
6. Ubiquitous language
A team for a project consists of different groups of persons with diverse expertise. Ubiquitous language is used by team members of a domain-driven design project to communicate efficiently with each other. This is necessary because each group of workers uses jargon to communicate within themselves. If there is no standardized language, it would defeat the aim of the team. One should bear in mind that the team spans from the domain experts to the users.
7. Value objects, entities, and aggregates
Entities are structures that have both data and behavior. This means that they can give valuable data for various purposes by exhibiting different behaviors; an example is a user. Value objects are structures that have attributes that are not independent; an instance of a value object is a shipping address.
The wider the system, the more number of value objects and entities. However, this could cause confusion and unnecessary complexity. It is best to group these structures logically according to their functions. These groups of structures are called aggregates. The aggregates are interconnected with each other and treated as a unit. Each unit has one object that other objects in different aggregates can reference. This object is called an aggregate root.
See More: DevOps vs. Agile Methodology: Key Differences and Similarities
Domain-Driven Design Process
The domain-driven design process (DDD) can be used for different purposes and to solve various problems. Although it has its advantages, it has its downsides in some cases. Therefore, it is best to work with specific practices to get the expected workflow and results.
1. Begin with modeling and requirements
The main point of a domain-driven design is the domain. You would need to know every single requirement and detail of the business. This is the first thing you must do, and do it diligently to avoid missing any critical points. You and the business analysts could deduce an effective domain model by asking relevant questions. If you do not focus on the business requirements, you will work with the wrong model.
2. Always work with flat aggregate roots
There are a few advantages of deep object graph nesting. However, there are more disadvantages as they make unit testing difficult, among other things. On the other hand, working with flat aggregate roots makes it easy to maintain and extend your units. It also makes repetitive activities easier.
Other advantages of keeping your aggregate roots flat include the following:
- It improves your performance as you would only load little data
- Requires less object-relational-mapping (ORM) configuration in object-oriented programming (OOP)
- It gives better output as it involves smaller transactions
3. Use the read model for complex systems
A read model is a model that is used for reads, as in queries. This read model takes events in the domain to construct a model that effectively responds to users’ questions. This read model can help you build and maintain in-memory data, relational data between aggregates, graph data models, documents, search indexes, etc.
4. Use domain events properly
People often misuse domain events because they do not know what domain events are. Domain events are facts in your model that one cannot change. Aggregate roots fire domain events. That said, do not try to change the aggregate root from which the domain event is fired. Also, it is best not to use domain events to acquire permission to run activities. Instead, you are to use domain events to notify the remaining parts of the domain model that something worth noting has happened.
5. Do not use aggregate roots to access repositories
This popular rule states that aggregates should not be used to access repositories. Instead, use application and domain services and event handlers to access repository interfaces.
See More: What Is Serverless? Definition, Architecture, Examples, and Applications
Pros and Cons of Domain-Driven Design Process
There are several reasons why this process has proved so popular. Some of its advantages are:
- Easy communication: One of the issues often associated with complex systems is inefficient communication. However, all team members can efficiently communicate amongst themselves with the ubiquitous language related to the domain model. The ubiquitous language consists of simpler terms eliminating the point of less technical jargon.
- Improved flexibility: Domain-driven design is a structural system based on object-oriented analysis and design. This implies that the system works with objects and will. This allows the system to be manipulated, improved, or dismantled. A developer can either alter the entire system or adjust the components individually.
- Improves domain interface instead of UI/UX: Domain-driven design is a concept that builds an interface based on the ideas of the domain given/advised by the domain experts themselves. This ensures that all applications with which the DDD is used would be perfectly suited to the domain according to its properties. This is an advantage over other applications that emphasizes the need for UI/UX before the fittings with the domain’s properties.
- User-oriented: In the design process, the domain fittings are to be considered before the user experience, as explained above. This gives birth to other advantages, like ensuring the company meets its user goals. Users would achieve this because if the domain is central in the design process, it provides a good product that would satisfy the needs of its users.
- Improved efficiency: By employing domain-driven design and working with domain experts, getting efficient and effective products is inevitable. As opposed to working with only developers that might not know the full details of the domain, domain experts would work to make products that have the necessary features. These products can easily indicate how the business operates.
However, there are also a few downsides to using a domain-driven design process:
- Requires highly experienced domain experts: The project will be unsuccessful from the beginning if the domain-driven design team does not have at least one domain expert who knows the subject’s ins and outs. The team should employ outside personnel that has knowledgeable experience with domains. This individual would work throughout the development cycle, giving various advice as the domain expert for the team. This is necessary to prevent wasted efforts.
- Repetitive activities: In most cases, the team would need to carry out various activities repeatedly to make a standard project that one can alter into necessary forms in the future. This might be a good thing for some organizations but a significant drawback for others. This is true, especially for organizations that might have used models that are not flexible to growth in the past. An example of such a model is the waterfall model.
- Inappropriate for highly-technical projects: Although the domain-driven design is appropriate for solving domain complexities, it might not be a good decision if the project has minor domain complexities with high technical complexities. This is because the technicalities might be too much for the domain experts to grasp, causing problems down the line.
- Time-consuming and easy to go wrong: This design takes a lot of time to implement as consistent communication, and repeated implementation of various activities is needed. In addition, it is very easy for things to go wrong. Repeated wrong steps could cause a spiral of wringing activities and yield a bad result.
See More: DevOps Roadmap: 7-Step Complete Guide
Domain-Driven Design Examples
This article uses a house loan processing system as an example of the application of domain-derived design. The business use case for this system is to approve the financing request for a home loan (mortgage). The following description will walk you through this approach:
- The mortgage application is sent to a lender, where it is first put through the “Underwriting” step. During this process, the loan application is reviewed by underwriters, who decide whether or not to approve it based on the specifics of the applicant’s income, credit history, and other relevant information.
- After the underwriters have reviewed the loan application and given their stamp of approval, the application is sent on to the “Closing and Funding” phases in the loan approval process.
- Transferring money to the borrower is handled automatically by the “Funding” module, which is part of the system that processes loans. The loan application package is typically sent to a title firm by the lender, often a bank, as the first step in the financing process.
- After that, the title firm examines the loan package and sets a closing date for the loan with the buyer and seller of the property to make sure everything is in order. The closing agent at the title firm arranges a meeting between the borrower and the seller so that they may sign the necessary documentation to transfer the property’s title.
The different modules designed in this entire application follow domain-driven design principles.
See More: Top 10 DevOps Automation Tools in 2021
Takeaway
Domain-driven design is among the most up-and-coming skills for developers and DevOps engineers. It ensures that websites, applications, and web apps are perfectly tuned to a company’s needs and the codebase remains reusable for the company in the long term. In industries that involve complex digital services – like the financial sector – domain-driven design is an important skill.
Did this article help you understand the pros and cons of single-page applications? Tell us on Facebook, Twitter, and LinkedIn. We’d love to hear from you!
MORE ON DEVOPS
