Domain-Driven Design
SkillMediaDomain-driven-design is a skill that helps an AI agent plan and route Domain-Driven Design work, from strategic modeling to tactical implementation and evented architecture patterns. It runs a viability check, produces strategic artifacts such as subdomains, bounded contexts and a language glossary, then routes to specialized skills for the current task.
Use Domain-Driven Design in Claude, ChatGPT or Ahel Desktop
Free. Sign in, add Domain-Driven Design and connect your AI. About a minute.
Also: Claude Code · Cursor · Codex
Then ask your AI: use the Domain-Driven Design skill
Details
Instructions available. Your AI can read the instructions. Execution depends on the setup they require.
Account requirements not reviewed. Check the skill instructions before use; ahel provides instructions and does not run this skill.
No other account needed.
Have access to domain knowledge or a proxy product expert before starting.
What your AI can do with it
- Run a viability check before committing to full DDD
- Produce subdomains, bounded contexts and a language glossary
- Route to @ddd-strategic-design for strategic model and boundaries
- Route to @ddd-context-mapping for cross-context integrations
- Route to @ddd-tactical-patterns for tactical code modeling
- Route to @cqrs-implementation, @event-sourcing-architect, @saga-orchestration
Getting started
- Have access to domain knowledge or a proxy product expert before starting.
- Add the domain-driven-design skill to your agent's available skills.
- Ask the agent to run a viability check on your domain to decide if full DDD is worth the added complexity.
- Have the agent produce strategic artifacts first: subdomains, bounded contexts and a language glossary.
- Let the agent route to the specialized skill that matches the current task, such as @ddd-tactical-patterns or @cqrs-implementation.
What this skill tells your AI
The instructions your AI receives, as published by davila7/claude-code-templates in cli-tool/components/skills/development/domain-driven-design/SKILL.md and read by ahel’s review.
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.
Signals
- GitHub stars
- 32k
- Forks
- 4k
- Last commit
- Oct 2026
Others that do the same job
Questions
- When should I use this skill?
- Use it when you need to model a complex business domain with explicit boundaries, decide whether full DDD is worth the added complexity, connect strategic design to implementation patterns, or plan CQRS, event sourcing, sagas or projections from domain needs.
- When should I not use this skill?
- Do not use it for simple CRUD with low business complexity, for localized bug fixes, or when there is no access to domain knowledge and no proxy product expert.
Advanced
- Item type
- skill
- Key
domain-driven-design-davila7- Source
- github.com/davila7/claude-code-templates
github.com/davila7/claude-code-templates