Learning Domain-Driven Design

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.

Problem

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

Solution

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