Domain Driven Design

In order to create good software, we must understand our customer's business. We  cannot create a prospect management software application unless we have a good understanding of how a sales pipeline works; We must understand the domain of sales. This is what Domain-Driven Design (DDD) is about. Look for layered application architecture diagram later in this chapter. What's in the center?

A firm understanding of our business domain and our requirements is the key to successfully engineering a system solution.

In this model we consider two main layers. The inside, with applicative use case handlers, and business domain logic and the outside, with all our infrastructure code, with database connections, and messaging.

Combining this model with the dependency inversion principle which states that high level modules should not depend on low level modules. We see that our dependencies should always point inwards towards the domain layer.

Interactions between those two areas are...