What is domain-driven design (DDD)?
Domain-driven design (DDD) is a software development philosophy centered around the business domain, or sphere of knowledge, of that software’s users. DDD emphasizes the importance of understanding and modeling the business domain for which a software application is being developed.
Eric Evans first introduced the concept of DDD in his book Domain-Driven Design: Tackling Complexity in the Heart of Software. This book, published in 2003, includes numerous schema, repositories, value objects and entities that can help developers express a meaningful and object-oriented programming (OOP) model that aligns with the business and its needs. The basic idea of DDD is to align software with the business needs it is meant to address, thus improving its quality and usability.
Domain-driven design leverages structures and principles of the object-oriented programming model.
Since DDD is about considering the specific business context in which software would operate, it emphasizes the use of a ubiquitous or common language for both software developers and business stakeholders. As a result, every class, method, variable, etc., in the software code reflects business reality and promotes business understanding, ensuring the program remains understandable to business users and usable in the domain for which it was developed.
DDD also encourages iterative collaboration. By collaborating closely with each other and the business, developers can build software that better reflects the business it is meant to serve. The iterative development approach often yields better-quality software aligned to business requirements.
In sum, the four main ideas of DDD are as follows:
Core domain. The business domain and its fundamental aspects — elements, entities, requirements, objectives — should be aligned with the software under development.
Model-driven design. A well-defined domain model represents the business domain and informs software development for that domain.
Ubiquitous language. A common language facilitates communication between the technical — i.e., development — and business teams.
Iterative collaboration. Ongoing iterative collaboration between developer and business stakeholders to exchange insights, provide feedback and enable continuous improvement in software.
Domain-driven design and business domains
To design from a domain-driven perspective, the business’s area of expertise or domain must be defined. There are supporting and core domains. The core domain of a business is unique and central to its operation, therefore receiving the majority of attention, time and resources in the development process. The supporting domains are more general, such as money, service or time.
These domains are then modeled out in language and corresponding code. If a domain can’t be defined in language easily, it is not ready for coding. If a change occurs in a domain of business, a corresponding code change is generally required.
Importance of domain-driven design
DDD can be most beneficial for complex projects with complex business logic. The approach enables the development of software focused on the requirements of users who need it. With its emphasis on creating a domain model, using a ubiquitous language and defining bounded contexts, DDD can help teams develop software that truly reflects a business domain and serves the needs of users in that domain.
Domain-driven design also eases communication about the project, minimizing the potential for misunderstandings and reducing the need for rework. Adopting the approach limits the dev team’s focus to needs that are central to the domain and helps them avoid wasting time and effort on anything unneeded.
Domain-driven design breaks down a platform into subdomains, which are mapped to microservices with their own endpoints.
Drawbacks of domain-driven design
A significant challenge for small or inexperienced development teams, and for teams with little or no knowledge of an organization’s business models and business processes, is that DDD requires extensive knowledge of a domain. Most often used by enterprise-level businesses, DDD can also be too complex and costly to implement for simpler applications.
DDD is poorly suited to highly technical projects and projects with simple business logic. For the former, the time and resources needed to implement DDD might be an insurmountable challenge, especially for smaller organizations or teams. For the latter, implementing DDD might simply be overkill. Its high investment of time and resources might not be commensurate with project benefits when those are expected to be minimal.
Another drawback of DDD is that adopting it requires both a mindset and cultural change. For developers used to working in a silo separated from the business, it can be difficult to start thinking about business domains, domain models, collaboration with the business and so forth. These difficulties can slow down development and software time to market.
Domain-driven design and object-oriented programming
DDD draws on object-oriented analysis and design. In many ways, DDD can be considered a way of applying OOP to business models. While the two approaches are not the same, they are frequently used in tandem. The two approaches — DDD, with its emphasis on modeling real-world concepts, and OOP, which is about encapsulating data and behavior into objects — work well together. They help teams create applications for real business needs and models.
DDD also has some overlaps with other development philosophies such as model-driven development (MDD), event sourcing and command query responsibility segregation (CQRS). Specifically, DDD can be used with MDD to create better domain models and software code, with CQRS to effectively separate the concerns of different parts of the system and event sourcing to manage the system’s state changes.
Domain-driven design overlaps with other development philosophies, such as CQRS.
Domain-driven design helps enterprises develop software focused on key business needs. Software architects must understand the fundamentals of bounded context to use it properly, however. Learn about using bounded context for effective domain-driven design.