Domain-Driven Design
FreeStrategically model complex business domains with DDD.
Free · Opens the source repo
What Domain-Driven Design does
The Domain-Driven Design (DDD) skill provides a structured approach to modeling complex business domains by defining explicit boundaries and connecting strategic decisions to tactical implementations. It is particularly useful for teams dealing with intricate business rules or those requiring a clear understanding of domain knowledge. This skill guides users through the process of assessing whether full DDD is appropriate for their project, helping to avoid unnecessary complexity in simpler scenarios.
Users can leverage this skill to produce essential strategic artifacts such as subdomains, bounded contexts, and a language glossary before diving into tactical implementation. The skill emphasizes the importance of a viability check, ensuring that DDD is only pursued when certain conditions are met, like complex business rules or unstable integration contracts. By following the outlined steps, teams can effectively route their work to specialized skills that address specific needs, such as CQRS implementation or event sourcing.
This skill is designed for software architects, developers, and project managers who are tasked with navigating the complexities of business domain modeling. It helps in aligning technical implementations with business goals, ensuring that the development process remains focused and efficient. By providing a clear routing map to other relevant skills, users can streamline their workflow and enhance collaboration across teams.
In summary, the Domain-Driven Design skill is a valuable resource for those looking to implement DDD principles effectively while avoiding over-engineering in simpler projects. It serves as a comprehensive guide for modeling, planning, and executing domain-driven initiatives.
When to use it
Use this skill when modeling complex domains or assessing the viability of full DDD for your project.
When not to use it
Avoid this skill for simple CRUD applications or when there's no access to domain knowledge.
What you can build with it
Assessing DDD Viability for a Payment System
Use the Domain-Driven Design skill to evaluate if a payment processing system should adopt full DDD based on its complexity.
Modeling a Multi-Team Project
Leverage this skill to define subdomains and bounded contexts for a project involving multiple teams to prevent model collisions.
Planning Event Sourcing for an Inventory System
Utilize this skill to plan event sourcing and CQRS for an inventory management system that requires auditability.
How to install Domain-Driven Design
View source1. Install with the skills CLI
npx skills add davila7/claude-code-templates/domain-driven-design --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by davila7Domain-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.
Frequently asked questions about Domain-Driven Design
Similar skills
Spring Boot Testing
Master testing techniques for Spring Boot 4 applications.
GitHub Issues
Manage GitHub issues efficiently with MCP tools.
Geofeed Tuner
Optimize your IP geolocation feeds in CSV format.
Batch Files
Master Windows batch scripting for automation and task management.
Adobe Illustrator Scripting
Automate your Illustrator workflows with ExtendScript.
Plugin Structure
Create and organize Claude Code plugins effectively.