ChatGPT
Claude
Codex CLI
Cohere
Cursor
DeepSeek
Gemini
GitHub Copilot
GLM
Grok
Kimi
Llama
MiniMax
Mistral
OpenAI
opencode
Skill
domain-driven-design
Plan and route Domain-Driven Design work from strategic modeling to tactical implementation and evented architecture patterns.
#architecture
Virus-scanned
Reviewed automatically before listing.
Download
sickn33-agentic-awesome-skills-skills_domain-driven-design-286166a.zip · 1 KB
This skill couldn't be refreshed from GitHub on the last check — you're seeing the last imported snapshot.
Install
skills CLI
npx skills add https://github.com/sickn33/agentic-awesome-skills/tree/main/skills/domain-driven-design
Claude Code
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install sickn33-agentic-awesome-skills@llmmart
Git
git clone https://github.com/sickn33/agentic-awesome-skills.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole sickn33/agentic-awesome-skills collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
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.
Files (agentic-awesome-skills)
-
references
-
ddd-deliverables.md 615 B
# 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
-
-
SKILL.md 2.4 KB
--- name: domain-driven-design description: "Plan and route Domain-Driven Design work from strategic modeling to tactical implementation and evented architecture patterns." risk: safe source: self tags: "[ddd, domain, bounded-context, architecture]" date_added: "2026-02-27" --- # 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.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.