Domain-driven design
Encyclopedia
Domain-driven design is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts. The premise of domain-driven design is the following:
Domain-driven design is not a technology or a methodology. DDD provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.
The term was coined by Eric Evans in his book of the same title.
Strategic Design is a set of principles for maintaining model integrity, distillation of the Domain Model and working with multiple models.
The following image demonstrates the patterns in Strategic Domain-Driven Design and the relationships between them.
Therefore:
Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside.
Continuous integration
When a number of people are working in the same bounded context, there is a strong tendency for the model to fragment. The bigger the team, the bigger the problem, but as few as three or four people can encounter serious problems. Yet breaking down the system into ever-smaller contexts eventually loses a valuable level of integration and coherency.
Therefore:
Institute a process of merging all code and other implementation artifacts frequently, with automated tests to flag fragmentation quickly. Relentlessly exercise the ubiquitous language to hammer out a shared view of the model as the concepts evolve in different people’s heads.
People on other teams won’t be very aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections. When connections must be made between different contexts, they tend to bleed into each other.
Therefore:
Identify each model in play on the project and define its bounded context. This includes the implicit models of non- object-oriented subsystems. Name each bounded context, and make the names part of the ubiquitous language.
Describe the points of contact between the models, outlining explicit translation for any communication and highlighting any sharing. Map the existing terrain.
in an object-oriented system with a multilayered architecture
. In DDD, there are artifacts to express, create, and retrieve domain models:
Example: Most airlines distinguish each seat uniquely on every flight. Each seat is an entity in this context. However, Southwest Airlines (or EasyJet/RyanAir for Europeans) does not distinguish between every seat; all seats are the same. In this context, a seat is actually a value object.
Example: When people exchange dollar bills, they generally do not distinguish between each unique bill; they only are concerned about the face value of the dollar bill. In this context, dollar bills are value objects. However, the Federal Reserve may be concerned about each unique bill; in this context each bill would be an entity.
Example: When you drive a car, you do not have to worry about moving the wheels forward, making the engine combust with spark and fuel, etc.; you are simply driving the car. In this context, the car is an aggregate of several other objects and serves as the aggregate root to all of the other systems.
: Although in theory, the general idea of DDD need not be restricted to object-oriented approaches, in practice DDD seeks to exploit the powerful advantages that object-oriented techniques make possible. These include entities/aggregate roots as receivers of commands/method invocations and the encapsulation of state within foremost aggregate roots and on a higher architectural level, bounded contexts. The reader should be aware that object orientation is not exclusive to OO-only languages, but can be a part of functional programming, also. Applying commands/method invocations to an entity or aggregate root can be seen as an application of a function to a data structure where the result of the function application is an identical data structure with different data and/or version (especially version if optimistic concurrency is used). In dynamic languages such as Ruby or Smalltalk, object instances can be queried on whether they support a method (by name and/or signature), which is similar to how a statically typed language might choose to use an inversion of control container (or a service bus, or a service locator) to support runtime lookup of the objects - services - that support a given protocol/method/command (see CQRS further down).
Model-driven engineering
(MDE)
Model-driven architecture
(MDA): While DDD is compatible with MDA, the intent of the two concepts is somewhat different. MDA is concerned more with the means of translating a model into code for different technology platforms than with the practice of defining better domain models.
POJOs
and POCOs
: POJOs and POCOs are technical implementation concepts, specific to the Java
and .NET framework
respectively. However, the emergence of the terms POJO and POCO, reflect a growing view that, within the context of either of those technical platforms, domain objects should be defined purely to implement the business behaviour of the corresponding domain concept, rather than be defined by the requirements of a more specific technology framework.
The naked objects
pattern: This pattern is based on the premise that if you have a good enough domain model, the user interface can simply be a reflection of this domain model; and that if you require the user interface to be direct reflection of the domain model then this will force the design of a better domain model.
Domain-specific language (DSL): DDD does not specifically require the use of a DSL, though it could be used to help define a DSL and support methods like domain-specific multimodeling
.
Aspect-oriented programming
(AOP): AOP makes it easy to factor out technical concerns (such as security, transaction management, logging) from a domain model, and as such makes it easier to design and implement domain models that focus purely on the business logic.
Command-query separation
(CQRS): CQRS an architectural pattern for separation of reads from writes where the former is a Query and the latter is a Command. Commands mutate state and are hence approximately equivalent to method invocation on your aggregate roots/entities and Queries query state, but do not mutate it. CQRS is a derivative architectural pattern from the design pattern called Command and Query Separation (CQS) which was coined by Meyer. While CQRS does not require DDD, domain driven design makes the distinction between commands and queries, explicit, around the concept of an aggregate root. The idea is that a given aggregate root has a method that corresponds to a command and a command handler invokes the method on the aggregate root. The aggregate root is responsible for performing the logic of the operation and yielding either a number of events or a failure (exception or execution result enumeration/number) response OR (if ES is not used) just mutating its state for a persister implementation such as an ORM to write to a data store, while the command handler is responsible for pulling in infrastructure concerns related to the saving of the aggregate root's state or events and creating the needed contexts (e.g. transactions).
Event Sourcing (ES): An architectural pattern which warrants that your entities (as per Evan's definition) do not track their internal state by means of direct serialization or O/R mapping, but by means of reading and committing events to an event store. Where ES is combined with CQRS and DDD, aggregate roots are responsible for thoroughly validating and applying commands (often by means having their instance methods invoked from a Command Handler) and then publishing a single or a set of events which is also the foundation upon which the aggregate roots base their logic for dealing with method invocations. Hence, the input is a command and the output is one or many events which are transactionally (single commit) saved to an event store and then often published on a message broker for the benefit of those interested (often the views are interested; they are then queried using Query-messages). When modeling your aggregate roots to output events you can isolate the internal state event further than would be possible when projecting read-data from your entities like is done in standard n-tier data-passing architectures. One significant benefit from this, is that tooling such as axiomatic theorem provers (e.g. Microsoft Contracts or CHESS) are easier to apply as the aggregate root comprehensively hide its internal state. Events are often persisted based on the version of the aggregate root instance, which yields a domain model that synchronizes in distributed systems around the concept of optimistic concurrency.
- Placing the project's primary focus on the core domain and domain logic
- Basing complex designs on a model
- Initiating a creative collaboration between technical and domain experts to iteratively cut ever closer to the conceptual heart of the problem.
Domain-driven design is not a technology or a methodology. DDD provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.
The term was coined by Eric Evans in his book of the same title.
Core definitions
- Domain: A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software.
- 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.
- Context: The setting in which a word or statement appears that determines its meaning.
Prerequisites for the successful application of DDD
- Your domain is not trivial
- The project team has experience and interest in OOP/OOD
- You have access to domain experts
- You have an iterative process
Strategic domain-driven design
Ideally, we would prefer to have a single, unified model. While this is a noble goal, in reality it always fragments into multiple models. It is more useful to recognize this fact of life and work with it.Strategic Design is a set of principles for maintaining model integrity, distillation of the Domain Model and working with multiple models.
The following image demonstrates the patterns in Strategic Domain-Driven Design and the relationships between them.
Bounded context
Multiple models are in play on any large project. Yet when code based on distinct models is combined, software becomes buggy, unreliable, and difficult to understand. Communication among team members becomes confused. It is often unclear in what context a model should not be applied.Therefore:
Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside.
Continuous integrationContinuous integrationIn software engineering, continuous integration implements continuous processes of applying quality control — small pieces of effort, applied frequently...
When a number of people are working in the same bounded context, there is a strong tendency for the model to fragment. The bigger the team, the bigger the problem, but as few as three or four people can encounter serious problems. Yet breaking down the system into ever-smaller contexts eventually loses a valuable level of integration and coherency.Therefore:
Institute a process of merging all code and other implementation artifacts frequently, with automated tests to flag fragmentation quickly. Relentlessly exercise the ubiquitous language to hammer out a shared view of the model as the concepts evolve in different people’s heads.
Context map
An individual bounded context leaves some problems in the absence of a global view. The context of other models may still be vague and in flux.People on other teams won’t be very aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections. When connections must be made between different contexts, they tend to bleed into each other.
Therefore:
Identify each model in play on the project and define its bounded context. This includes the implicit models of non- object-oriented subsystems. Name each bounded context, and make the names part of the ubiquitous language.
Describe the points of contact between the models, outlining explicit translation for any communication and highlighting any sharing. Map the existing terrain.
Building blocks of DDD
In the book Domain-Driven Design, a number of high-level concepts and practices are articulated, such as ubiquitous language meaning that the domain model should form a common language given by domain experts for describing system requirements, that works equally well for the business users or sponsors and for the software developers. The book is very focused at describing the domain layer that is one of the common layersCommon layers in an information system logical architecture
The following four layers are the most common layers in a logical multilayered architecture for an information system with an object-oriented design:* User Interface Layer...
in an object-oriented system with a multilayered architecture
Multilayered architecture
A multilayered software architecture is using different layers for allocating the responsibilities of an application.There is also an architectural pattern that is named Layers and has been described in different publications, including the book Pattern-Oriented Software ArchitectureA System of...
. In DDD, there are artifacts to express, create, and retrieve domain models:
- EntityEntityAn entity is something that has a distinct, separate existence, although it need not be a material existence. In particular, abstractions and legal fictions are usually regarded as entities. In general, there is also no presumption that an entity is animate.An entity could be viewed as a set...
: An object that is not defined by its attributes, but rather by a thread of continuity and its identityIdentity (object-oriented programming)An identity in object-oriented programming, object-oriented design and object-oriented analysis describes the property of objects that distinguishes them from other objects. This is closely related to the philosophical concept of identity....
.
Example: Most airlines distinguish each seat uniquely on every flight. Each seat is an entity in this context. However, Southwest Airlines (or EasyJet/RyanAir for Europeans) does not distinguish between every seat; all seats are the same. In this context, a seat is actually a value object.
- Value Object: An object that contains attributes but has no conceptual identity. They should be treated as immutable.
Example: When people exchange dollar bills, they generally do not distinguish between each unique bill; they only are concerned about the face value of the dollar bill. In this context, dollar bills are value objects. However, the Federal Reserve may be concerned about each unique bill; in this context each bill would be an entity.
- Aggregate: A collection of objects that are bound together by a root entity, otherwise known as an aggregate root. The aggregate root guarantees the consistency of changes being made within the aggregate by forbidding external objects from holding references to its members.
Example: When you drive a car, you do not have to worry about moving the wheels forward, making the engine combust with spark and fuel, etc.; you are simply driving the car. In this context, the car is an aggregate of several other objects and serves as the aggregate root to all of the other systems.
- Service: When an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services. The Service concept is called "Pure Fabrication" in GRASP.
- Repository: methods for retrieving domain objects should delegate to a specialized Repository object such that alternative storage implementations may be easily interchanged.
- Factory: methods for creating domain objects should delegate to a specialized FactoryFactory method patternThe factory method pattern is an object-oriented design pattern to implement the concept of factories. Like other creational patterns, it deals with the problem of creating objects without specifying the exact class of object that will be created.The creation of an object often requires complex...
object such that alternative implementations may be easily interchanged.
Relationship to other ideas
Object-oriented analysis and designObject-oriented analysis and design
Object-oriented analysis and design is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterised by its class, its state , and its behavior...
: Although in theory, the general idea of DDD need not be restricted to object-oriented approaches, in practice DDD seeks to exploit the powerful advantages that object-oriented techniques make possible. These include entities/aggregate roots as receivers of commands/method invocations and the encapsulation of state within foremost aggregate roots and on a higher architectural level, bounded contexts. The reader should be aware that object orientation is not exclusive to OO-only languages, but can be a part of functional programming, also. Applying commands/method invocations to an entity or aggregate root can be seen as an application of a function to a data structure where the result of the function application is an identical data structure with different data and/or version (especially version if optimistic concurrency is used). In dynamic languages such as Ruby or Smalltalk, object instances can be queried on whether they support a method (by name and/or signature), which is similar to how a statically typed language might choose to use an inversion of control container (or a service bus, or a service locator) to support runtime lookup of the objects - services - that support a given protocol/method/command (see CQRS further down).
Model-driven engineering
Model-driven engineering
Model-driven engineering is a software development methodology which focuses on creating and exploiting domain models , rather than on the computing concepts...
(MDE)
Model-driven architecture
Model-driven architecture
Model-driven architecture is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model-driven architecture is a kind of domain engineering, and supports model-driven engineering of...
(MDA): While DDD is compatible with MDA, the intent of the two concepts is somewhat different. MDA is concerned more with the means of translating a model into code for different technology platforms than with the practice of defining better domain models.
POJOs
Plain Old Java Object
In computing software, POJO is an acronym for Plain Old Java Object. The name is used to emphasize that a given object is an ordinary Java Object, not a special object...
and POCOs
Plain Old CLR Object
Plain Old CLR Object or POCO is a play on the term POJO, from the Java EE programming world, and is used by developers targeting the Common Language Runtime of the .NET Framework....
: POJOs and POCOs are technical implementation concepts, specific to the Java
Java (programming language)
Java is a programming language originally developed by James Gosling at Sun Microsystems and released in 1995 as a core component of Sun Microsystems' Java platform. The language derives much of its syntax from C and C++ but has a simpler object model and fewer low-level facilities...
and .NET framework
.NET Framework
The .NET Framework is a software framework that runs primarily on Microsoft Windows. It includes a large library and supports several programming languages which allows language interoperability...
respectively. However, the emergence of the terms POJO and POCO, reflect a growing view that, within the context of either of those technical platforms, domain objects should be defined purely to implement the business behaviour of the corresponding domain concept, rather than be defined by the requirements of a more specific technology framework.
The naked objects
Naked objects
Naked objects is an architectural pattern used in software engineering.-Definition:The naked objects pattern is defined by three principles:...
pattern: This pattern is based on the premise that if you have a good enough domain model, the user interface can simply be a reflection of this domain model; and that if you require the user interface to be direct reflection of the domain model then this will force the design of a better domain model.
Domain-specific language (DSL): DDD does not specifically require the use of a DSL, though it could be used to help define a DSL and support methods like domain-specific multimodeling
Domain-specific multimodeling
Domain-specific multimodelingis a software development paradigm where each view is made explicit as a separate domain-specific language .Successful development of a modern enterprise system requires the convergence of multiple views...
.
Aspect-oriented programming
Aspect-oriented programming
In computing, aspect-oriented programming is a programming paradigm which aims to increase modularity by allowing the separation of cross-cutting concerns...
(AOP): AOP makes it easy to factor out technical concerns (such as security, transaction management, logging) from a domain model, and as such makes it easier to design and implement domain models that focus purely on the business logic.
Command-query separation
Command-query separation
Command-query separation is a principle of imperative computer programming. It was devised by Bertrand Meyer as part of his pioneering work on the Eiffel programming language....
(CQRS): CQRS an architectural pattern for separation of reads from writes where the former is a Query and the latter is a Command. Commands mutate state and are hence approximately equivalent to method invocation on your aggregate roots/entities and Queries query state, but do not mutate it. CQRS is a derivative architectural pattern from the design pattern called Command and Query Separation (CQS) which was coined by Meyer. While CQRS does not require DDD, domain driven design makes the distinction between commands and queries, explicit, around the concept of an aggregate root. The idea is that a given aggregate root has a method that corresponds to a command and a command handler invokes the method on the aggregate root. The aggregate root is responsible for performing the logic of the operation and yielding either a number of events or a failure (exception or execution result enumeration/number) response OR (if ES is not used) just mutating its state for a persister implementation such as an ORM to write to a data store, while the command handler is responsible for pulling in infrastructure concerns related to the saving of the aggregate root's state or events and creating the needed contexts (e.g. transactions).
Event Sourcing (ES): An architectural pattern which warrants that your entities (as per Evan's definition) do not track their internal state by means of direct serialization or O/R mapping, but by means of reading and committing events to an event store. Where ES is combined with CQRS and DDD, aggregate roots are responsible for thoroughly validating and applying commands (often by means having their instance methods invoked from a Command Handler) and then publishing a single or a set of events which is also the foundation upon which the aggregate roots base their logic for dealing with method invocations. Hence, the input is a command and the output is one or many events which are transactionally (single commit) saved to an event store and then often published on a message broker for the benefit of those interested (often the views are interested; they are then queried using Query-messages). When modeling your aggregate roots to output events you can isolate the internal state event further than would be possible when projecting read-data from your entities like is done in standard n-tier data-passing architectures. One significant benefit from this, is that tooling such as axiomatic theorem provers (e.g. Microsoft Contracts or CHESS) are easier to apply as the aggregate root comprehensively hide its internal state. Events are often persisted based on the version of the aggregate root instance, which yields a domain model that synchronizes in distributed systems around the concept of optimistic concurrency.
Software tools to support domain-driven design
Practicing DDD does not depend upon the use of any particular software tool or framework. Nonetheless, there is a growing number of open-source tools and frameworks that provide support to the specific patterns advocated in Evans' book or the general approach of DDD. Among these are:- ActifsourceActifsourceActifsource is a domain specific modeling workbench. It is realized as plug-in for the software development environment Eclipse. Actifsource supports the creation of multiple domain models which can be linked together. It comes with a UML-like graphical editor to create domain specific languages...
is a plug-in for EclipseEclipse (software)Eclipse is a multi-language software development environment comprising an integrated development environment and an extensible plug-in system...
which enables software development combining DDD with model-driven engineeringModel-driven engineeringModel-driven engineering is a software development methodology which focuses on creating and exploiting domain models , rather than on the computing concepts...
and code generationAutomatic programmingIn computer science, the term automatic programming identifies a type of computer programming in which some mechanism generates a computer program to allow human programmers to write the code at a higher abstraction level....
. - ECO (Domain Driven Design)ECO (Domain Driven Design)ECO , is a software framework suited for Domain-Driven-Design from , designed to increase productivity by utilizing facilities such as Object-relational mapping for persisting domain objects, UML models for domain classes and executable State Machines for behavior control defined in UML notation...
: Framework with database, class, code and state machine generation from UML diagrams by CapableObjects. - Habanero.NETHabanero.NETHabanero is an Enterprise Application Framework for the .NET platform that provides tools for rapid application development using agile techniques. Habanero uses object-relational mapping to carry out data persistence from relational databases to objects in code, and provides runtime user...
(Habanero) is an Open Source Enterprise Application framework for creating Enterprise applications using the principles of Domain-driven design and implemented in .NET.NET FrameworkThe .NET Framework is a software framework that runs primarily on Microsoft Windows. It includes a large library and supports several programming languages which allows language interoperability...
. - ManyDesigns PortofinoManyDesigns PortofinoManyDesigns Portofino is an open-source web application framework written in Java, supporting several commercial and open source databases, and based on the Struts2 MVC framework...
is an open source, model-driven web-application framework for high productivity and maintainability. It provides CRUD forms, relationships, workflow management, dashboards, breadcrumbs, searches, single sign-on, permissions, and reporting. - OpenMDXOpenMDXOpenMDX is an open source model-driven architecture software platform, a framework suited for domain-driven design . It is based on the Object Management Group's MDA standards. OpenMDX supports Java SE, Java EE, and .NET runtime environments...
: Open source, Java based, MDA Framework supporting Java SE, Java EE, and .NET.NET FrameworkThe .NET Framework is a software framework that runs primarily on Microsoft Windows. It includes a large library and supports several programming languages which allows language interoperability...
. OpenMDX differs from typical MDA frameworks in that "use models to directly drive the runtime behavior of operational systems". - OpenXavaOpenXavaOpenXava is a web application framework for developing business applications in an effective way. It not only allows rapid and easy development of CRUD modules and report generation, but also provides flexibility to develop complex real life business applications like accounting packages, customer...
: Generates an AJAXAjax- Mythology :* Ajax , son of Telamon, ruler of Salamis and a hero in the Trojan War, also known as "Ajax the Great"* Ajax the Lesser, son of Oileus, ruler of Locris and the leader of the Locrian contingent during the Trojan War.- People :...
application from JPAJava Persistence APIThe Java Persistence API, sometimes referred to as JPA, is a Java programming language framework managing relational data in applications using Java Platform, Standard Edition and Java Platform, Enterprise Edition....
entities. Only it's needed to write the domain classes to obtain a ready to use application.
Examples of DDD
- DDD Sample Application: Java DDD sample application based on cargo example from Domain-Driven Design book.
- NDDD Sample Application: C# port of the Java DDD sample application based on cargo example from Domain-Driven Design book.
- Bullsfirst Trading System: Sample application demonstrating DDD applied to a real world scenario, using current and emerging technologies.
External links
- Eric Evans on Domain Driven Design - Putting the Model to Work
- Eric Evans on Domain Driven Design - Strategic Design
- Jimmy Nilsson on Domain Driven Design
- Domain-Driven Design forum (English)
- An Introduction to Domain Driven Design
- Qi4j a framework for domain centric application development, including evolved concepts from AOP, DI and DDD
- Plugger - a framework for domain driven design java applications.
- JdonFramework is a light-weight framework for developing Domain-Driven Design applications in the spirit of Evans
- Romaframework a Domain Driven Design approach framework
- Greg Young, CQRS, Task Based UIs, Event Sourcing agh!
- Jon Jenkins of Clever Labs on Domain Driven Design's importance in the business
- Udi Dahan clarifies CQRS and how it relates to other patterns
- SkillsCast (footage, code, slides) of Greg Young, explaining CQRS is of great use for building things other than server side systems
- SkillsCast of Udi Dahan on Asynchronous Systems Architecture for the Web
- video recording of Eric Evans' on Defining DDD recorded at the DDD eXchange 2010
- Dan Haywood's interview on InfoQ about Domain Driven Design using Naked Objects