Expert guidance for Domain-Driven Design architecture and implementation. Use when designing complex business systems, defining bounded contexts, structuring domain models, choosing between modular monolith vs microservices, implementing aggregates/entities/value objects, or when users mention "DDD", "domain-driven design", "bounded context", "aggregate", "domain model", "ubiquitous language", "event storming", "context mapping", "domain events", "anemic domain model", strategic design, tactical patterns, or domain modeling. Helps make architectural decisions, identify subdomains, design aggregates, and avoid common DDD pitfalls.
This skill inherits all available tools. When active, it can use any tool Claude has access to.
references/anti-patterns.mdreferences/architecture-alignment.mdreferences/strategic-patterns.mdreferences/tactical-patterns.mdDDD manages complexity through alignment between software and business reality. Strategic design (boundaries, language, subdomains) provides more value than tactical patterns (aggregates, repositories).
Apply DDD when:
DDD is overkill when:
| Type | Investment | Example |
|---|---|---|
| Core | Maximum - competitive advantage | Recommendation engine, trading logic |
| Supporting | Custom but quality tradeoffs OK | Inventory management |
| Generic | Buy/outsource | Auth, email, payments |
Customer, OrderMoney, Address, EmailDefault to value objects. Only use entities when identity matters.
Start with modular monolith when:
├── Team < 20 developers
├── Domain boundaries unclear
├── Time-to-market critical
└── Strong consistency required
Consider microservices when:
├── Bounded contexts have distinct languages
├── Teams can own full contexts
├── Independent scaling required
└── DevOps maturity exists