What Is It?

Domain driven design is about focusing on the complexity that is intrinsic to the business domain itself.

Domain driven design is intended for domains with complex business logic, rather than techinical complexity. It is about how to model the domain-specific logic.

Destinguish the core domain, unique to the business, from the supporting subdomains that are generic.

Consists of a set of patterns for building enterprise applications from the domain model out.

Aims to create models of the problem domain, and leave generic problems for later (things like persistence, GUI, and messaging). You need to understand the part of the problem that is unique to your business.

This is not just about making a diagram. All diagrams are views of the model: your business code. At the same time, the ulimate goal of domain driven development is to provide a solution to the business, not to write code.

Focus on one subdomain at a time. Divide and conquer.


A common application architecture is Layered Architecture.

The UI Layer relies on the Business Logic Layer which relies on the Data Layer. All three layers rely on the Intrastructure.

Onion Architecture

The recommended domain driven design architecture is the Onion Architecture. This is only appropriate for large, long-lived applications, or for applications with complex business behavior.

Onion architecture uses interfaces for behavior contracts, and forces externalization of the infrastructure.

The Domain Model (objects) lies in the center. The Domain Services rely on the Domain Model. The Application Services rely on the Domain Services. This makes up the Application Core.

The UI, Tests, and Infrastructure are all satellites to the Application Code. These outer layer concerns are expected to change often, far more often that the business behavior.

The basic idea of Onion is that Layer X can rely on more-central layers, but never of more-outer layers.

Domain Model Layer

The domain model layer (or just domain layer) is the heart of the business application.

The domain layer is for representing concepts of the business, information about the business situation, and business rules.
Bounded Context

A bounded context defines where a model is valid.

For example, an application includes an appointment scheduler and billing. The model "Client" in the scheduler just includes "Name". The model "Client" in billing includes "Credit Card" and "Address". Both "Client" models are part of a different bounded context.

By explicitly dividing these contexts, you can use focused models instead of sharing a single too-large model.

All models are only valid without their contexts. Do not try to make a multi-context model.

Sub Domain Vs Bounded Context

A sub domain is a piece of the problem space. A bounded context is a piece of the solution space. Usually, they will correspond to each other.

Context Map

A diagram showing the relationships among all the bounded contexts, and how each is defined.
Shared Kernel

Usually shared utilities, like user authentication. Any "cross cutting concerns".
Core Domain

The key differentiator of your client's business. This functionality cannot be outsourced, and must be executed well.

Sub Domain

Separate applications or features your software must support or interact with.
Domain Models

A domain model is made up of many object.

Anemic Domain Model

An anemic model is focused on the state of its objects. The object don't have much behavior.

For example, objects with many fields/properties and just basic CRUD logic.

Rich Domain Model

The objects contain the business logic directly.

This is recommended in domain driven design.

It is critical to communicate extensively with the domain experts (your clients) throughout the project.

One draw back is that your clients need a lot of time and willingness to talk to you about the project throughout it.

Ubiquitous Language

It is critical to communicate using the langauage of your clients. Do not attempt to make them learn your language, they won't. Learn the terminology your clients use, and use that terminology in your documentation, in your database, and in your code.

Always seek confirmation from the client about your understanding of the business. If their terminology is ambiguous, reach a shared agreement with them about what terms mean what.

You may have a different ubiquituous language for different bounded contexts.