domain-driven-design

# Domain-Driven Design ## Use this skill when - You need to model a complex business domain with explicit boundaries. - You want to decide whether full DDD is worth the added complexity. - You need to connect strategic design decisions to implementation patterns. - You are planning CQRS, event sourcing, sagas, or projections from domain needs. ## Do not use this skill when - The problem is simple CRUD with low business complexity. - You only need localized bug fixes. - There is no access to domain knowledge and no proxy product expert. ## Instructions 1. Run a viability check before committing to full DDD. 2. Produce strategic artifacts first: subdomains, bounded contexts, language glossary. 3. Route to specialized skills based on current task. 4. Define success criteria and evidence for each stage. ### Viability check Use full DDD only when at least two of these are true: - Business rules are complex or fast-changing. - Multiple teams are causing model collisions. - Integration contracts are unstable. - Auditability and explicit invariants are critical. ### Routing map - Strategic model and boundaries: `@ddd-strategic-design` - Cross-context integrations and translation: `@ddd-context-mapping` - Tactical code modeling: `@ddd-tactical-patterns` - Read/write separation: `@cqrs-implementation` - Event history as source of truth: `@event-sourcing-architect` and `@event-store-design` - Long-running workflows: `@saga-orchestration` - Read models: `@projection-patterns` ...