Nw Domain Driven Design
Strategic and tactical DDD patterns, bounded context discovery, context mapping...
Install
npx skills add nWave-ai/nWave --skill nw-domain-driven-design -g -a claude-code -y- Repository
- nWave-ai/nWave628
- Category
- Design
- Updated
- 2mo ago
- License
- MIT
- Context cost
- Mediumabout 2,722 tokens
- Runs scripts
- No, instructions only
What it does
Strategic and tactical DDD patterns, bounded context discovery, context mapping, aggregate design rules, and decision frameworks for when to apply DDD
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 (simplified) | Buy/integrate |
| DDD investment | Full strategic + tactical | Pragmatic tactical | Minimal/none |
| Developer allocation | Senior/best talent | Mid-level | Junior/integration |
Bounded Contexts
A bounded context is the boundary within which a particular domain model is defined and applicable. Different from subdomains: a bounded context is a software boundary; a subdomain is a problem-space concept. They should align but are not the same.
