domain-driven-design
Guidance for implementing complex business domains using DDD architectural patterns.
Install
mkdir -p .claude/skills/domain-driven-design && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/13371" && unzip -o skill.zip -d .claude/skills/domain-driven-design && rm skill.zipInstalls to .claude/skills/domain-driven-design
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Plan and route Domain-Driven Design work from strategic modeling to tactical implementation and evented architecture patterns.Key capabilities
- →Run a viability check for full DDD adoption
- →Produce strategic artifacts like subdomains and bounded contexts
- →Define a language glossary for the domain
- →Route to specialized skills for tactical code modeling
- →Plan CQRS, event sourcing, sagas, or projections
- →Define success criteria and evidence for each DDD stage
How it works
The skill first assesses the viability of DDD, then guides the creation of strategic artifacts, and routes to specific patterns for tactical implementation or evented architectures.
Inputs & outputs
When to use domain-driven-design
- →Modeling business domains
- →Defining bounded contexts
- →Planning event-sourced architectures
About this skill
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
- Run a viability check before committing to full DDD.
- Produce strategic artifacts first: subdomains, bounded contexts, language glossary.
- Route to specialized skills based on current task.
- 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-architectand@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
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.
When not to use it
- →The problem is simple CRUD with low business complexity
- →The task only needs localized bug fixes
- →There is no access to domain knowledge and no proxy product expert
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
How it compares
This skill provides a structured approach to DDD, from initial viability assessment to routing specific implementation patterns, ensuring a methodical application of the methodology.
Compared to similar skills
domain-driven-design side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| domain-driven-design (this skill) | 0 | 5mo | No flags | Advanced |
| d365-technical-plan-designer | 0 | 3mo | No flags | Advanced |
| Context7 MCP Rule | 0 | 5mo | No flags | Beginner |
| messaging-decision | 0 | 1mo | No flags | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by RJsolucoes
View all by RJsolucoes →You might also like
d365-technical-plan-designer
williamzhou1216
D365 技术设计与实施计划编排专家（把 spec 转成 plan）
Context7 MCP Rule
dlwlrmjlo
Always use the Context7 MCP server when foundational planning or architecture decisions are being made.
messaging-decision
Brilhante29
Decide whether a portfolio repository should use no broker, transactional outbox, RabbitMQ, Kafka/Redpanda, Redis Streams, or NATS based on delivery semantics, ordering, replay, retry/DLQ, throughput, and benchmark evidence.
architecture-patterns
wshobson
Implement proven backend architecture patterns including Clean Architecture, Hexagonal Architecture, and Domain-Driven Design. Use when architecting complex backend systems or refactoring existing applications for better maintainability.
kotlin-multiplatform
vitorpamplona
Platform abstraction decision-making for Amethyst KMP project. Guides when to abstract vs keep platform-specific, source set placement (commonMain, jvmAndroid, platform-specific), expect/actual patterns. Covers primary targets (Android, JVM/Desktop, iOS) with web/wasm future considerations. Integrates with gradle-expert for dependency issues. Triggers on: abstraction decisions ("should I share this?"), source set placement questions, expect/actual creation, build.gradle.kts work, incorrect placement detection, KMP dependency suggestions.
nodejs-best-practices
davila7
Node.js development principles and decision-making. Framework selection, async patterns, security, and architecture. Teaches thinking, not copying.