Closing Words

To complete our exploration of domain-driven design I want to get back to the quote we started with:

There is no sense in talking about the solution before we agree on the problem, and no sense talking about the implementation steps before we agree on the solution.

Efrat Goldratt-Ashlag

This quote neatly summarizes our DDD journey.


To provide a software solution, we first have to understand the problem: what is the business domain that we are working in, what are the business goals, and what is the strategy for achieving them.

We used the ubiquitous language to gain a deep understanding of the business domain and its logic that we have to implement in software.

You learned to manage the complexity of the business problem by breaking it apart into bounded contexts. Each bounded context implements a single model of the business domain, aimed at solving a specific problem.

We discussed how to identify and categorize the building blocks of business domains: core, supporting, and generic subdomains. Table E-1 compares these three types of subdomains.

Table E-1. The three types of subdomains
Subdomain type Competitive advantage Complexity Volatility Implementation Problem
Core Yes High High In-house Interesting
Generic No High Low Buy/adopt Solved
Supporting No Low Low In-house/outsource Obvious


You learned to leverage this knowledge to design solutions optimized for each type of subdomain. We discussed four business logic implementation ...

Get Learning Domain-Driven Design now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.