# Nw Domain Driven Design

Strategic and tactical DDD patterns, bounded context discovery, context mapping...

- Repository: https://github.com/nWave-ai/nWave (628 stars)
- Category: Design
- License: MIT
- Last updated: 2026-09-16
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add nWave-ai/nWave --skill nw-domain-driven-design -g -a claude-code -y`
Codex: `npx skills add nWave-ai/nWave --skill nw-domain-driven-design -g -a codex -y`
Cursor: `npx skills add nWave-ai/nWave --skill nw-domain-driven-design -g -a cursor -y`
Gemini CLI: `npx skills add nWave-ai/nWave --skill nw-domain-driven-design -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add nWave-ai/nWave`

## Description

Strategic and tactical DDD patterns, bounded context discovery, context mapping, aggregate design rules, and decision frameworks for when to apply DDD

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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.

The rest: https://github.com/nWave-ai/nWave/blob/HEAD/nWave/skills/nw-domain-driven-design/SKILL.md