Domain-Driven Design splits the domain (business) logic into defined spheres of knowledge. It was originally defined by Eric Evans in Domain-Driven Design: Tackling Complexity in the Heart of Software as the three principles:

  1. Focus on the core domain its logic.
  2. Base complex designs on models of the domain.
  3. Collaborate with domain experts to improve the application model and resolve domain-related issues.

DDD is declarative: programming in this model is effectively creating a domain-specific language for your problem domain.

When to use it


  • Eases communication by enforcing common language and constraining interaction between contexts.
  • Flexibility achieved through encapsulation and modularity via effective use of object-oriented design.
  • Domain over interface avoids ill-fitting abstractions and helps to keep the application understandable to its audience.


  • Requires robust domain expertise throughout the development lifecycle.
  • Encourages iterative practices.
  • Poorly suited to highly technical projects, as domain experts may be unable to appreciate the technical challenges associated with a domain.


  • The Context is the setting in which a word or statement appears which defines its meaning -- statements about a model can only be understood in a context.
  • A Model is a system of abstractions that describe and can solve problems within selected elements of a domain.
  • Ubiquitous Language is language structured around the domain model used by all members of the team to connect all of the activities of the team with the software.
  • A Bounded Context describes a boundary (e.g. a subsystem, module or team's scope) within which a particular model applies.


  • An Entity is an always-consistent object that describes a domain model.
  • A Value Object is an immutable object with attributes, but no identity.
  • Domain Events are objects used to record discrete events related to model activity domain experts care about.
  • Aggregates are clusters of Entities and Value Objects contained in a defined boundary, which can interact with the rest of the system through a single Aggregate Root. These allows separation of contexts.
  • A Service contains functionality that doesn't fit directly within an Entity or Value Object.
  • Repositories provide methods for creation, modification and deletion of objects within an Aggregate, centralising business logic outside of the model.
  • Factories encapsulate the logic for creation of complex objects and Aggregates.