Domain-driven design

16 languages

• Article
• Talk
• Read
• Edit
• View history
Tools

•
•
•
•
•
•
•
•
•
•
•

•
•
Appearance
hide
Text

•
Small
Standard
Large
Width

•
Standard
Wide
Color (beta)

•
Automatic
Light
Dark
From Wikipedia, the free encyclopedia

Part of a series on

Software development

show
 Core activities

show

Paradigms and models

show

Methodologies and frameworks

show

Supporting disciplines

show

Practices

show

Tools

show

Standards and bodies of knowledge

show

Glossaries

show

Outlines

• v
• t
• e

Domain-driven design (DDD) is a major software design approach,[1] focusing on

modeling software to match a domain according to input from that domain's
experts.[2] DDD is against the idea of having a single unified model; instead it divides a
large system into bounded contexts, each of which have their own model. [3]

Under domain-driven design, the structure and language of software code (class
names, class methods, class variables) should match the business domain. For
example: if software processes loan applications, it might have classes like "loan
application", "customers", and methods such as "accept offer" and "withdraw".
Domain-driven design is predicated on the following goals:

• placing the project's primary focus on the core domain and domain logic layer;
• basing complex designs on a model of the domain;
• initiating a creative collaboration between technical and domain experts to iteratively
refine a conceptual model that addresses particular domain problems.
Critics of domain-driven design argue that developers must typically implement a great
deal of isolation and encapsulation to maintain the model as a pure and helpful
construct. While domain-driven design provides benefits such as maintainability,
Microsoft recommends it only for complex domains where the model provides clear
benefits in formulating a common understanding of the domain.[4]

The term was coined by Eric Evans in his book of the same name published in 2003.[5]

Overview
[edit]

Domain-driven design articulates a number of high-level concepts and practices.[5]

Of primary importance is a domain of the software, the subject area to which the user
applies a program. Software's developers build a domain model: a system of
abstractions that describes selected aspects of a domain and can be used to solve
problems related to that domain.

These aspects of domain-driven design aim to foster a common language shared by

domain experts, users, and developers—the ubiquitous language. The ubiquitous
language is used in the domain model and for describing system requirements.

Ubiquitous language is one of the pillars of DDD together with strategic

design and tactical design.

In domain-driven design, the domain layer is one of the common layers in an object-
oriented multilayered architecture.

Kinds of models
[edit]

This article needs additional citations for verification. Please help improve
this article by adding citations to reliable sources. Unsourced material may be
challenged and removed.
Find sources: "Domain-driven design" –
news · newspapers · books · scholar · JSTOR (July 2023) (Learn how and when to
remove this message)

Domain-driven design recognizes multiple kinds of models. For example, an entity is an

object defined not by its attributes, but its identity. As an example, most airlines assign a
unique number to seats on every flight: this is the seat's identity. In contrast, a value
object is an immutable object that contains attributes but has no conceptual identity.
When people exchange business cards, for instance, they only care about the
information on the card (its attributes) rather than trying to distinguish between each
unique card.

Models can also define events (something that happened in the past). A domain event
is an event that domain experts care about. Models can be bound together by a root
entity to become an aggregate. Objects outside the aggregate are allowed to hold
references to the root but not to any other object of the aggregate. The aggregate root
checks the consistency of changes in the aggregate. Drivers do not have to individually
control each wheel of a car, for instance: they simply drive the car. In this context, a car
is an aggregate of several other objects (the engine, the brakes, the headlights, etc.).

Working with models

[edit]

In domain-driven design, an object's creation is often separated from the object itself.

A repository, for instance, is an object with methods for retrieving domain objects from a
data store (e.g. a database). Similarly, a factory is an object with methods for directly
creating domain objects.

When part of a program's functionality does not conceptually belong to any object, it is
typically expressed as a service.

Relationship to other ideas

[edit]

A bounded context is analogous to a microservice.[6]

Although domain-driven design is not inherently tied to object-oriented approaches, in

practice, it exploits the advantages of such techniques. These include entities/aggregate
roots as receivers of commands/method invocations, the encapsulation of state within
foremost aggregate roots, and on a higher architectural level, bounded contexts.

As a result, domain-driven design is often associated with Plain Old Java

Objects and Plain Old CLR Objects, which are technically technical implementation
details, specific to Java and the .NET Framework respectively. These terms reflect a
growing view that domain objects should be defined purely by the business behavior of
the domain, rather than by a more specific technology framework.

Similarly, the naked objects pattern holds that the user interface can simply be a
reflection of a good enough domain model. Requiring the user interface to be a direct
reflection of the domain model will force the design of a better domain model.[7]

Domain-driven design has influenced other approaches to software development.

Domain-specific modeling, for instance, is domain-driven design applied with domain-

specific languages. Domain-driven design does not specifically require the use of a
domain-specific language, though it could be used to help define a domain-specific
language and support domain-specific multimodeling.

In turn, aspect-oriented programming makes it easy to factor out technical concerns

(such as security, transaction management, logging) from a domain model, letting them
focus purely on the business logic.

Model-driven engineering and architecture

[edit]

While domain-driven design is compatible with model-driven engineering and model-

driven architecture,[8] the intent behind the two concepts is different. Model-driven
architecture is more concerned with translating a model into code for different
technology platforms than defining better domain models.

However, the techniques provided by model-driven engineering (to model domains, to

create domain-specific languages to facilitate the communication between domain
experts and developers,...) facilitate domain-driven design in practice and help
practitioners get more out of their models. Thanks to model-driven engineering's model
transformation and code generation techniques, the domain model can be used to
generate the actual software system that will manage it.[9]

Command Query Responsibility Segregation

[edit]

Command Query Responsibility Segregation (CQRS) is an architectural pattern for

separating reading data (a 'query') from writing to data (a 'command'). CQRS derives
from Command and Query Separation (CQS), coined by Bertrand Meyer.

Commands mutate state and are approximately equivalent to method invocation on

aggregate roots or entities. Queries read state but do not mutate it.

While CQRS does not require domain-driven design, it makes the distinction between
commands and queries explicit with 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 either
yielding a failure response or just mutating its own state that can be written to a data
store. The command handler pulls in infrastructure concerns related to saving the
aggregate root's state and creating needed contexts (e.g., transactions).

Event sourcing
[edit]

Event sourcing is an architectural pattern in which entities track their internal state not
by means of direct serialization or object-relational mapping, but by reading and
committing events to an event store.

When event sourcing is combined with CQRS and domain-driven design, aggregate
roots are responsible for validating and applying commands (often by having their
instance methods invoked from a Command Handler), and then publishing events. This
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 saved to an event store, and then often published on a message
broker for those interested (such as an application's view).

Modeling aggregate roots to output events can isolate internal state even further than
when projecting read-data from entities, as in standard n-tier data-passing architectures.
One significant benefit is that axiomatic theorem provers (e.g. Microsoft Contracts and
CHESS[10]) are easier to apply, as the aggregate root comprehensively hides 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 through optimistic
concurrency.

Notable tools
[edit]

Although domain-driven design does not depend on any particular tool or framework,
notable examples include:

• Actifsource, a plug-in for Eclipse which enables software development combining

DDD with model-driven engineering and code generation.
• Context Mapper, a Domain-specific language and tools for strategic and tactic
DDD.[11]
• CubicWeb, an open source semantic web framework entirely driven by a data
model. High-level directives allow to refine the data model iteratively, release after
 release. Defining the data model is enough to get a functioning web application.
Further work is required to define how the data is displayed when the default views
are not sufficient.
• OpenMDX, an open-source, Java-based, MDA Framework supporting Java
SE, Java EE, and .NET. OpenMDX differs from typical MDA frameworks in that "use
models to directly drive the runtime behavior of operational systems".
• Restful Objects, a standard for mapping a Restful API onto a domain object model
(where the domain objects may represent entities, view models, or services). Two
open source frameworks (one for Java, one for .NET) can create a Restful Objects
API from a domain model automatically, using reflection.