Domain-Driven Design (Eric Evans)
Main Argument
The hard part of most software is the complexity of the domain, not the technology. The way to manage it is to build a rigorous model of the domain, bind that model tightly to the code, and express it in a single shared language used by developers and domain experts alike. At scale no one model can cover everything, so models are scoped to explicit boundaries, and design effort is concentrated on the part of the domain that actually differentiates the business. The durable content is this strategic design reasoning, not the tactical building blocks (entities, aggregates, repositories) that sit closer to implementation.
Key Takeaways
- A domain model is a deliberate, selective abstraction of the business, and in model-driven design the model and the code shape each other so they never drift apart.
- The ubiquitous language is one rigorous vocabulary for the model, used in speech, documents, and code; awkwardness in the language is a defect in the model, not a translation problem to tolerate.
- A bounded context is the explicit boundary within which a model and its language apply. The same term can mean different things in different contexts, so integration between contexts is made explicit rather than forced into one universal model.
- The context map is the strategic picture of how bounded contexts relate and integrate; an anti-corruption layer protects one model from another's concepts.
- The core domain is where the business differentiates. Spend the best people and the deepest modeling there; minimize, buy, or outsource generic and supporting subdomains.