Domain Driven Design

Structure, practices and terminology for making design decisions in complex software.

What is a domain?

The field for which a system is built.

Airport management, insurance sales, coffee shops, orbital flight, you name it.
It's not unusual for an application to span several different domains. For example,
an online retail system might be working in the domains of shipping (picking
appropriate ways to deliver, depending on items and destination), pricing
(including promotions and user-specific pricing by, say, location), and
recommendations (calculating related products by purchase history).

What is a model?

"A useful approximation to the problem at hand." -- Gerry Sussman

An Employee class is not a real employee. It models a real employee. We know
that the model does not capture everything about real employees, and that's not
the point of it. It's only meant to capture what we are interested in for the
current context.

Different domains may be interested in different ways to model the same thing.
For example, the salary department and the human resources department may model
employees in different ways.

What is Domain-Driven Design (DDD)?

It is a development approach that deeply values the domain model and connects
it to the implementation. DDD was coined and initially developed by Eric Evans
in his great book Domain-Driven Design: Tackling Complexity in the Heart of Software.

You can read more about DDD here:

• An Introduction to Domain Driven Design
• Domain Driven Design Quickly - Great Book!
• Common DDD mistakes

Effective Aggregate Design

WIP Notes:

• Avoid transactional errors in multi-user environment
• http://dddcommunity.org/library/vernon_2011/

Subscribe to domain events to integrate bounded contexts