Domain-Driven Design is a software development methodology that tackles complexity by aligning software architecture with business domains through collaborative modeling. Introduced by Eric Evans in 2003, DDD provides both strategic patterns (bounded contexts, context mapping, ubiquitous language) for organizing large systems and tactical patterns (entities, aggregates, value objects, repositories) for implementing rich domain models. The core insight: complex business logic belongs in the domain layer, encapsulated within clearly defined boundaries that reflect how domain experts naturally think about and describe their work — making software not just functional, but maintainable and evolvable as business understanding deepens over time.
What This Cheat Sheet Covers
This topic spans 18 focused tables and 115 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Strategic Design — Subdomain Types
Every system contains multiple subdomains; the strategic challenge is classifying each correctly so you invest effort where it creates the most competitive value.
| Type | Example | Description |
|---|---|---|
Netflix: recommendation algorithm Amazon: fulfillment & logistics | • Where competitive advantage lives — requires best developers and custom solutions • uniqueness defines business success • never outsource | |
E-commerce: inventory management Bank: report generation | • Necessary for business but not differentiating — can be built in-house with simpler approaches • does not require full DDD complexity |