Browse Definitions :

domain-driven design (DDD)

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.

Diagram of the structure of object-oriented programming.
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.

Diagram of domain-driven design.
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.

Diagram of the steps in the CQRS pattern.
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.

This was last updated in June 2024

Continue Reading About domain-driven design (DDD)

  • subnet (subnetwork)

    A subnet, or subnetwork, is a segmented piece of a larger network. More specifically, subnets are a logical partition of an IP ...

  • secure access service edge (SASE)

    Secure access service edge (SASE), pronounced sassy, is a cloud architecture model that bundles together network and cloud-native...

  • Transmission Control Protocol (TCP)

    Transmission Control Protocol (TCP) is a standard protocol on the internet that ensures the reliable transmission of data between...

  • cyber attack

    A cyber attack is any malicious attempt to gain unauthorized access to a computer, computing system or computer network with the ...

  • digital signature

    A digital signature is a mathematical technique used to validate the authenticity and integrity of a digital document, message or...

  • What is security information and event management (SIEM)?

    Security information and event management (SIEM) is an approach to security management that combines security information ...

  • product development (new product development)

    Product development -- also called new product management -- is a series of steps that includes the conceptualization, design, ...

  • innovation culture

    Innovation culture is the work environment that leaders cultivate to nurture unorthodox thinking and its application.

  • technology addiction

    Technology addiction is an impulse control disorder that involves the obsessive use of mobile devices, the internet or video ...

  • organizational network analysis (ONA)

    Organizational network analysis (ONA) is a quantitative method for modeling and analyzing how communications, information, ...

  • HireVue

    HireVue is an enterprise video interviewing technology provider of a platform that lets recruiters and hiring managers screen ...

  • Human Resource Certification Institute (HRCI)

    Human Resource Certification Institute (HRCI) is a U.S.-based credentialing organization offering certifications to HR ...

Customer Experience
  • contact center agent (call center agent)

    A contact center agent is a person who handles incoming or outgoing customer communications for an organization.

  • contact center management

    Contact center management is the process of overseeing contact center operations with the goal of providing an outstanding ...

  • digital marketing

    Digital marketing is the promotion and marketing of goods and services to consumers through digital channels and electronic ...