A comprehensive introduction to Domain-Driven Design (DDD) covering both strategic and tactical aspects. Strategic design includes ubiquitous language, bounded contexts, context maps, and subdomain classification (core, supporting, generic). Tactical building blocks covered include entities, value objects, aggregates, domain services, application services, domain events, factories, and repositories. The post also connects DDD to code health metrics like cyclomatic complexity and CRAP score, explains common anti-patterns (anemic domain model, one enterprise model, oversized aggregates), and clarifies when DDD is and isn't appropriate. Practical techniques like EventStorming are mentioned for collaborative domain modeling.
Table of contents
TL;DR: What Domain-Driven Design Actually IsHow I Came to Take DDD SeriouslyThe Design Problem DDD Is Actually SolvingStrategic Design: The Half of DDD People SkipModeling With the Domain ExpertTactical Design: The Building Blocks Inside a Bounded ContextFactories: Building Objects Without Leaking the RecipeLayered, Hexagonal, Clean: Where DDD Sits in Your ArchitectureDDD and Complexity Metrics: Keeping Contexts HealthyCommon DDD Anti-PatternsWhen DDD Pays Off, and When It Does NotIn the End, Domain-Driven Design Is About OrganizationFrequently Asked Questions About Domain-Driven Design37 Impressions