[Book Club] Domain-Driven Design Chapter 15 - Distillation

The previous chapter covered strategies for the interaction between contexts. This chapter returns to the domain itself. It offers strategies for two situations. In the first, the original system never marked out its domain. In the second, the project grew, the domain became huge, and the concepts turned blurry.

This chapter also makes one point very strongly. Most developers, and senior engineers in particular, spend a lot of time on logic outside the core of the domain. They then overlook the Core Domain. The Core Domain is the most important part, and it is the part that deserves careful design.

---

Core Domain

1. The Core Domain is the most important part of the system. It is hard to cover this part with outsourcing or with an existing package.
2. You must separate the most valuable and most specialized concepts in the software. That separation compresses the Core Domain.
3. A Domain Vision Statement usually gives you the direction.

Strategies for separation

1. Generic Subdomain
   1. These are the general principles in the model that everybody knows. They are not the focus of the system.
   2. Solutions
      • An off-the-shelf open source project or product => it can be too detailed, or you do not understand it well enough. Integration also has a cost.
      • A published design or model => it does not match what you need.
      • Outsourcing => you must communicate with the outsourced team.
      • Your own implementation => you can underestimate the development cost and the maintenance burden.
   3. Example: the time zone model in a global shipping system.
   4. A generic concept does not have to be reused.
2. Domain Vision Statement => the broad positioning of the product, not the technical implementation.
3. Highlight Core => mark the core.
4. Cohesive Mechanism
   1. Some parts serve the Core Domain but do not form a subdomain. Separate those parts as a framework. The Core Domain then calls the methods of the framework through a public interface.
   2. Example: the route algorithm in a shipping system may be too complex. You can put a set of interfaces in the Core Domain and hide the algorithm behind them.
5. Segregated Core
   1. This handles the case where some elements belong to the core and other elements only give support.
   2. Refactor to separate the supporting part.
   3. This makes the core clear and easy to understand. However, the part that you separate out can be complex, tangled and obscure.
6. Abstract Core
   1. Vertical cuts and horizontal cuts.
   2. The core has to pull out too many modules and then reference them. The interactions between those modules are too complex.
   3. Use polymorphism to abstract what the subdomains have in common, and hide it behind a single interface.

Closing thoughts

When you need to refactor, focus on the most central part. Pull the core out. Finish the separation of the core, and you solve the problem at its root.