Domain Driven Design
Decide whether full DDD is worth it, produce strategic boundaries, and route the agent to the right tactical DDD skills before you code the wrong model.
Overview
domain-driven-design is an agent skill most often used in Validate (also Build backend and PM) that plans DDD from strategic boundaries through tactical and evented architecture routing.
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill domain-driven-designWhat is this skill?
- Viability check: commit to full DDD only when at least two complexity signals apply
- Strategic artifacts first—subdomains, bounded contexts, ubiquitous language glossary
- Routing map to specialized skills for strategic design, context mapping, and tactical patterns
- Connects domain needs to CQRS, event sourcing, sagas, and projections planning
- Explicit success criteria and evidence per stage before implementation
- Full DDD recommended only when at least two of four viability signals are true
- Four-step instruction flow: viability, strategic artifacts, routing, success criteria
Adoption & trust: 1 installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
Your SaaS domain is getting tangled across features and services, and you lack a disciplined way to decide if DDD—and which DDD step—fits before coding.
Who is it for?
Indie founders shipping multi-module APIs or agents where business rules, team boundaries, or integration contracts are unstable.
Skip if: Simple CRUD apps, one-off bug fixes, or efforts with zero access to domain knowledge and no stand-in product expert.
When should I use this skill?
You need to model a complex business domain, decide if full DDD is justified, or plan CQRS, event sourcing, sagas, or projections from domain needs.
What do I get? / Deliverables
You get a viability decision, strategic boundary artifacts, and a routed next focus (strategic, integration, or tactical) with success criteria before implementation starts.
- DDD viability assessment with evidence
- Strategic artifacts outline: subdomains, bounded contexts, glossary
- Routing recommendation to the next specialized DDD skill for the current task
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Strategic modeling and viability gates belong before heavy implementation—Validate scope is where you bound the domain and integration contracts. Subdomains, bounded contexts, and glossary work define what you will actually build, preventing model collisions during later backend work.
Where it fits
Run the viability check and draft bounded contexts before committing to a microservice split.
Translate context boundaries into integration contracts before implementing aggregates and repositories.
Align feature epics with subdomain ownership so agent-generated tasks do not cross context lines.
Verify new endpoints respect context boundaries and explicit invariants before release.
How it compares
Architecture planning router with explicit anti-CRUD gates—not a code generator or a single bounded-context implementation template.
Common Questions / FAQ
Who is domain-driven-design for?
Solo builders and small teams modeling non-trivial business domains who need strategic boundaries before backend and event-driven implementation choices.
When should I use domain-driven-design?
During Validate scoping when rules are complex; during Build backend/PM when contexts collide; before Ship review when integration contracts need explicit translation layers.
Is domain-driven-design safe to install?
It is documentation and routing only—review the Security Audits panel on this page; risk is low, but follow your repo policies when linked skills touch code.
SKILL.md
READMESKILL.md - 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` - Decision log: `@architecture-decision-records` If templates are needed, open `references/ddd-deliverables.md`. ## Output requirements Always return: - Scope and assumptions - Current stage (strategic, tactical, or evented) - Explicit artifacts produced - Open risks and next step recommendation ## Examples ```text Use @domain-driven-design to assess if this billing platform should adopt full DDD. Then route to the right next skill and list artifacts we must produce this week. ``` ## Limitations - This skill does not replace direct workshops with domain experts. - It does not provide framework-specific code generation. - It should not be used as a justification to over-engineer simple systems. # DDD Deliverables Checklist Use this checklist to keep DDD adoption practical and measurable. ## Strategic deliverables - Subdomain map (core, supporting, generic) - Bounded context map and ownership - Ubiquitous language glossary - 1-2 ADRs documenting critical boundary decisions ## Tactical deliverables - Aggregate list with invariants - Value object list - Domain events list - Repository contracts and transaction boundaries ## Evented deliverables (only when required) - Command and query separation rationale - Event schema versioning policy - Saga compensation matrix - Projection rebuild strategy