My collegues asked me to write down some documentation on the basic concepts of domain driven design. Why not make a blog post out of it?

Domain Driven Design is all about the domain. The premise is, that what we call model, is the model of the real world process we are going to implement (the “domain”). DDD focuses on the domain of the problem, not on data, not on functions, not on control structures (although all of this stuff is used to implement them). Object technology fits pretty well into DDD as it allows us to narrow reality, as we can express behavior and state together (in an object).

A short glossary

Domain Layer

The layer in the application where the domain is expressed in terms of objects.

Domain Objects

All the objects in the domain layer

Entity

Entities are those domain objects that are equal by identity as they express a specific state of a specific entity in the system. Examples are a customer or a purchase.

Value Object

The opposite of entities in the domain layer. Objects that are equal because of equal values not because they are identical. A money object is a typical value object and so is an address.

Aggregate

An aggregate is an objects graph in the domain layer consisting of entity and value objects. A customer has a number of addresses and an order has a money value object.

Aggregate root

The top level object in an aggregate. In the customer example, the customer is the aggregate root and all the other objects are aggregations to the customer.

Repository

The repository acts like a Facade to the ORM components of a system. In DDD we focus only on the domain, we don’t care about ORM, we are ignorant against ORM. The repository allows us to be ignorant as it provides a simple, collection like interface to the user. Think of the repository as a factory to the persisted objects with a collection interface and being a facade to keep away all that sad details of ORM.

Ubiquitous Language

At the beginning everything is messy: you think that girl is stupid, she thinks you are a quirky nerd with strange hobbies and even more strange friends. A few dates later you both find an ubiquitous language which allows you to communicate efficiently. DDD encourages to find a set of terms to describe the system, that is modeled after the language of the domain. So the knowledge gathered in the development team about the domain is directly build into the systems core.