Domain-Driven Design (DDD) is an approach to software development that simplifies the complexity developers face by connecting the implementation to an evolving model.
If we were to take a concept, divide it into four ingredients, and stir them together or take the same concept and serve it as four different items on a plate, which would be more effective? Let’s use food as an example — say, a bowl of chili. We know that chili is made by taking different ingredients (such as meat, sauce, and beans), placing them in a pot, and cooking for 30 to 45 minutes. In contrast, we have steak, potatoes, and vegetables on a plate, ready to be served.
Which one would be easier to manage if we were to add/remove items: taking beans and diced tomatoes out of a bowl of chili or removing vegetables from a plate and adding another food item? In this case, chili represents Data-Driven Design. Layers of ingredients in sequence with one another in an order (such as beans, meat, tomatoes, and sauce) complete the recipe.
Let’s compare this to Domain-Driven Design, where you have the domain (steak), Bounded Contexts (vegetables), and Single Responsibility Principle (potatoes), and either one could be replaced by something different outside of the domain and the meal will still be considered a full dish. Being able to add/remove from organized software is how DDD functions, which is why it is important for software developers and business owners to use.
The purpose of DDD is to:
- Provide principles & patterns to solve difficult problems
- Base complex designs on a model of the domain
- Initiate a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses domain problems
As developers, we are excited to jump into a project, start coding, and build software. However, we cannot build software without understanding the client’s needs first. DDD places a great amount of emphasis on not only comprehending what the client wants but working with them as partners through a project. The end goal is not only to write code, or even to build software, but to solve problems!
Understanding Domain-Driven Design
To understand DDD better, we need to know what the first “D” means — Domain. Domain is a sphere of knowledge and activity where the application logic revolves. In the world of Software Engineering, domain refers to the subject area to which the application is intended to apply.
DDD was created to make the domain the focus of design. DDD was initially introduced and made popular by a programmer named Eric Evans with his 2004 book, Domain-Driven Design: Tackling Complexity in the Heart of Software. Inside Eric’s book, he further defines a few common terms that are useful when describing and discussing DDD practices:
- Context: The setting in which a word or statement appears that determines its meaning. Statements about a model can only be understood in context.
- Model: A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
- Ubiquitous Language: A language structured around the domain model and used by all team members to connect all the activities of the team with the software.
- Bounded Context: A description of a boundary (typically a subsystem or the work of a specific team) within which a model is defined and applicable.
The emphasis of DDD is on understanding how to create an abstract model of the problem domain which can be implemented in a set of technologies. DDD, which is known as a methodology, provides guidelines for how model development and technology development can result in a system that meets the needs of its users while also being robust in the face of change in problem domain.
How to Use Domain-Driven Design
So how do we use DDD? Well, we can start by describing how the DDD process works.
The process of Domain-Driven Design involves collaboration between developers and non-developers. Ideally, one will have a shared model (which is a model that can be shared between a different Bounded Context) with shared languages so that as people from different domains with different perspectives discuss the solution, they have a shared knowledge base with shared concepts. You can find a list of concepts here.
Advantages and Disadvantages of Domain–Driven Design
DDD is a great approach to use for software development. However, it is not recommended for every project. DDD has advantages and disadvantages, and it is important for developers to know what they are before using the DDD approach for a project.
Advantages of DDD
- Patterns: Domain-Driven Design gives software developers the principles and patterns to solve tough problems in software and, at times, in business.
- Business Logic: Domain-Driven Design creates business logic by explaining requirements from a domain perspective. Conceptualizing the system software in terms of the business domain, reducing the risk of misunderstanding between the domain experts and the development team.
- Successful History: Domain-Driven Design has a history of success with complex projects, aligning with the experience of software developers and software applications developed.
Disadvantages of DDD
- Instant time consumption: Software Developers have to spend lots of time with domain experts to understand the domain thoroughly. Deciding the sub domains and system boundaries could also take a lot of time.
- Higher Learning Curve: Domain-Driven Design has a high learning curve. Developing a new way of thinking might seem painful at first. To help with the high learning curve, I recommend John Sonmez’s “10 Steps to Learn Anything Quickly”.
- Not ideal if complexity isn’t an issue: DDD was designed to simplify complexity. A lot of times complexity isn’t an issue in software development, such as CRUD (Create, Read, Update and Delete) or when developing Data-Driven applications. DDD is a great approach to software development if there is a need to simplify, but is not necessary if there isn’t.
Overall, DDD is worth learning because it simplifies one factor that is complex in every professional relationship: communication. DDD allows developers, domain experts, DBAs, business owners, and (most importantly) clients to communicate effectively with each other in order to solve problems.
Effectively Communicate with Domain-Driven Design
Domain-Driven Design is an effective way to write clear, testable code, and provides principles and patterns to solve difficult problems. Clients are typically not interested in how the code works or even how the software is built, but they are interested in a product that works. Communicating effectively with the client in regards to their product without being extremely technical is one of the greatest benefits DDD has to offer.