Many years ago a talented software designer added an editing feature he called “Divide and Conquer” to a popular newspaper layout program. This feature was well-designed, but nobody used it. Here’s why:

1. The name “divide and conquer” had no meaning in relation to newspaper layout.
2. Nobody could explain what the feature did or why you would use it.
3. Nobody asked for the feature and nobody wanted it.

Essentially, more focus was placed on what could be done with the program instead of considering why it should be done. 

Enter domain-driven design (DDD), an approach to software development that focuses on fully understanding the domain where the software will be applied. When you understand the domain, you reduce the risk of adding features that your customers don’t need or want.

What is domain-driven design (DDD)?

Software is meant to make our lives easier. It can streamline and automate real-world processes, or address areas of interest to specific users. The things that software addresses are the domains that the software is intended to work in. For example, the domain of Digital Audio Workstation (DAW) software is the audio recording industry.  

A software developer named Eric Evans recognized the need to understand the software domain. To introduce the DDD approach, he wrote a book called Domain-Driven Design: Tackling Complexity in the Heart of Software. In his book, Evans says, “The heart of software is its ability to solve domain-related problems for its user. All other features, vital though they may be, support this basic purpose.”

So, in our newspaper layout example above, you don’t need to be a professional layout editor to design helpful layout software. But you do need to understand how layout editors do their jobs if you want to make software that reflects their real-world processes and procedures. Any features beyond what they need add little to no value.

Guiding principles of domain-driven design

Basically, domain-driven design is about developing software that models real-world systems and processes. This approach is based on the following guiding DDD principles:

• Focus on the core domain: Before you begin coding, talk to people who work in that domain. They can help you to define all of the processes, procedures, and terminology of that domain. For example, if you are designing software to manage retail inventory, talk to the people who manage the store inventory rather than employees in HR or finance.
• Reduce complexity by basing designs on domain models: When you understand the business domain, create a model that is a reflection of the real-world domain. For example, your inventory management software should include features that are important to inventory managers such as inventory trend analysis, automatic restocking, barcode scanning, and so on. The model is a diagram, chart, or written paragraph that represents the organization and abstraction of the domain expert’s knowledge.
• Speak a common language: In his book, Evans talks about the importance of ubiquitous language. Everybody involved in the project should use the same language to talk about the domain. Listen to the words and phrases your domain experts use. Adopt the same terminology in your requirements document, in the model, and in the code itself.

Key domain-driven design terms

The following common key terms are helpful when learning about DDD:

• Domain logic: Also called business logic. This is the purpose of your model and software design. The design is based on the logic of real-world business rules that are translated to programming code.
• Design patterns: If there is existing code that solves a problem similar to one you’re working on, adapt it for your use. Don’t try to reinvent the wheel every time.   
• Context: The setting or environment that determines the meaning of a word, action, or feature within the software domain. For example, in a certain context it may make more sense to use an “Apply” button instead of a “Save” button.
• Bounded context: Large projects usually have many models that need to be integrated. A context boundary defines the logical frame in which a model can evolve. This helps other teams understand what they have to do to make their models valid when they are added to others.
• Context mapping: A document, graph, or diagram that outlines the relationships among multiple bounded contexts. The map shows each context’s language, independent implementation, and the interface used to communicate with other bounded contexts.
• Entities: An entity is a domain object that is defined by its unique identifier rather than by attributes. For example, a person buys a ticket to see a movie. The person is an entity because the unique identifier defines who that person is regardless of changes to hair color, weight, height, and so on. 
• Value objects: An unchangeable object that has attributes, but no distinct identity. For example, you buy a movie ticket that does not include assigned seating. All seats in the theater are the same. The seats are bolted down and can’t be moved, but your ticket lets you select any available seat. In this context, the seat is a value object.

Advantages of domain-driven design

The most obvious advantage of DDD is that it gets everybody to use the same language. When development teams use the same language as domain experts, it leads to software design that makes sense to the end user. Because the terminology in the application corresponds to real-world activities, there is less confusion and users will understand how to use the product more quickly.

Other benefits of DDD include:

• Business and development are aligned: Because they use the same language, developers have better communication and understanding when talking with the business team. This alignment reduces the risk of confusion and misunderstanding between the development team and the domain experts.
• Protects domain knowledge: Valuable knowledge is not lost when teams move on to other projects and when new people are brought in to maintain existing projects.
• More flexibility: The context definitions and boundaries make it easier to deal with requirement changes because everybody has the same understanding of the business domain.
• Easy to track: Better communication and a common set of terminology make it easier to track requirement implementation.
• Better application balance: Sometimes there is too much emphasis on the software UX/UI. These are important, but can lead to trouble if some of the domain requirements are neglected. It doesn’t matter how pretty your program is if it doesn’t do what the users want it to do. Focus on addressing what the domain needs and what the domain experts recommend so that the resulting software is balanced to suit customer needs and expectations.
• Better code: Following a DDD approach ultimately gives you cleaner, more reliable code. It also can establish repeatable best practices and design patterns to make future projects run more smoothly and efficiently.

Disadvantages of domain-driven design

Domain-driven design offers a lot of advantages, but it won’t necessarily work for everyone in every situation. A few disadvantages include:

• Requires extensive domain knowledge: You need to have at least one domain expert on the team. This expert must understand everything about the domain where the software is meant to be applied. Without that kind of knowledge, you could end up with features that don’t fit into the domain context.
• Only works if the domain is complex: If the domain is relatively simple, DDD could be time-consuming overkill. For example, the development of software in a job application domain may only require some simple forms for entering personal information, previous work experience, references, emergency contacts, and so on. If you don’t need a dedicated domain expert, then you probably don’t need DDD.
• May not work well in highly technical projects: Focusing on complex business domains and business logic works well because you can develop a common language among developers and domain experts. However, when the project is technically complex, it’s difficult to establish a common language that can be understood by people on the business side.
• Can be time consuming: Unless your developers are already domain experts, they will have to spend a lot of time with the business team to thoroughly understand the domain. But taking this time can eventually become an advantage when all of the domain knowledge is captured. 

Tips for implementing domain-driven design

Domain-driven design doesn’t have to be overwhelming. If you’re interested in adopting DDD principles in your organization, use these tips to start off on the right foot:

1. Start small. Don’t try to apply domain-driven design across the board in one fell swoop. Start with one piece of your application and begin applying DDD principles there. Limiting the scope to start will familiarize you with DDD and give you practice applying it. 
2. Continually learn and improve. After starting small, you can build on what you learn and start to expand your scope. Implementing domain-driven design won’t necessarily be a linear experience. You will likely run into roadblocks and challenges you’ll need to work through and iterate on. Embrace continual learning to improve on your work over time. 
3. Use DDD diagramming tools. Domain-driven design helps you model real-world systems and processes. Using an intelligent diagramming solution like Lucidchart not only makes modeling easier, it also gives stakeholders a clear, bird’s eye view of a system or application you’re mapping.
   
   A good DDD diagram can communicate complex relationships to non-technical stakeholders and illuminate potential opportunities or problem areas in the code. Lucidchart’s template and shapes library makes it easy to customize your own flowcharts and share your DDD diagrams with teams and stakeholders both in and outside of the organization for streamlined collaboration and communication.

If your organization wants to create software that fits well into its intended business domain, consider implementing domain-driven design. Even if DDD is not right for you, it’s still worth learning because it can help you improve communication among your development teams and domain experts. Better communication leads to better problem solving and more useful software.