nw-domain-driven-design

# Domain-Driven Design ## When to Apply DDD DDD addresses domain complexity (business rules, language, boundaries), not technical complexity (scaling, performance). Apply selectively. | Domain Type (Cynefin) | DDD Investment | Approach | |------------------------|----------------|----------| | Clear/Simple | None -- use CRUD | Standard patterns, no modeling overhead | | Complicated | Tactical only | Expert analysis, pragmatic patterns suffice | | Complex | Full strategic + tactical | Iterative modeling, bounded contexts, continuous refinement | | Chaotic | Stabilize first | Emergency patches, then apply DDD incrementally | ### Signs You Need DDD - Domain experts and developers frequently misunderstand each other - Business rules are complex, interconnected, frequently changing - Multiple teams work on the same codebase with conflicting models - System has grown into a "big ball of mud" - Business logic scattered across services, controllers, database procedures ### Signs DDD Is Overkill - Simple CRUD without complex business rules - Technical complexity outweighs domain complexity - Small team, small codebase, single bounded context - For simple microservices, anemic domain model is acceptable (not an anti-pattern) ## Strategic DDD ### Subdomain Classification | Criterion | Core | Supporting | Generic | |-----------|------|------------|---------| | Competitive advantage | Yes | No | No | | Unique to organization | Yes | Partially | No | | Build or buy | Build | Build ...