domain-driven-design
Helps plan and organize Domain-Driven Design work. It's useful for structuring complex projects and defining software architecture.
What it does
Helps plan and organize Domain-Driven Design work, from initial strategy to practical implementation, especially for complex systems.
When to use it
- ✓When the business is complex and changes rapidly.
- ✓If multiple teams need to work together without conflicts.
- ✓To connect planning decisions with how the code will be written.
Example of what to ask your AI
“Assess if we should use Domain-Driven Design for our payment platform and what the next steps are.”
Want more? Open the sections below.
How to use
The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.
Skill link
Ready-to-paste message
How it works
First, it checks if DDD is suitable for your problem. Then, it helps define the business parts and how they communicate, guiding you to the right tools for each stage.
Installation
Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.
In the terminal (Claude Code, Codex, Cursor), in your project folder:
npx skills add sickn33/agentic-awesome-skills --skill domain-driven-designOr download just the file:
curl -L https://raw.githubusercontent.com/sickn33/agentic-awesome-skills/main/plugins/agentic-awesome-skills-claude/skills/domain-driven-design/SKILL.md -o SKILL.mdTechnical content (original SKILL.md)
Original text by the author, straight from GitHub.
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.
FAQ
What is Domain-Driven Design (DDD)?
It's a way to organize software development by focusing on deeply understanding the 'domain' (the business problem) and how it works, especially in complex systems.
When is DDD really necessary?
It's most useful when business rules are complicated, change frequently, or when multiple teams need to collaborate on a large, integrated system.
Does this tool write the code for me?
No, it helps plan and organize the work but doesn't generate code directly or replace conversations with domain experts.
Details
Original description by the author
Plan and route Domain-Driven Design work from strategic modeling to tactical implementation and evented architecture patterns.
Popularity
- GitHub stars
- 48k
- Ranking position
- #2874
- License
- MIT
- Updated
- 10/15/2026
Comments
- …
More skills from this repository
00-andruia-consultant
Helps your agent start or improve AI projects. It analyzes code, suggests tools, and creates action plans in Spanish.
sickn33/agentic-awesome-skills
007
Lets your agent perform security audits and threat modeling. It's useful for protecting projects against attacks and vulnerabilities.
sickn33/agentic-awesome-skills
10-andruia-skill-smith
Helps your agent create or improve AI tools. It defines how tools work, writes documentation, and validates the structure.
sickn33/agentic-awesome-skills
20-andruia-niche-intelligence
Lets your agent create a summary about a specific industry. It's useful for understanding the context, rules, usage patterns, and risks of a project, using reliable sources.
sickn33/agentic-awesome-skills
Similar skills
api-connector-builder
Has your agent build new API connections following the existing pattern. Use when you need to add one more integration without creating a new way of doing things.
affaan-m/ECC
api-design
Helps your agent design REST APIs following best practices. It's useful for defining how APIs communicate, how errors are shown, and how to organize data.
affaan-m/ECC
backend-patterns
Helps your agent with server-side architecture patterns and database optimization. It's useful for building or reviewing code that runs on the server.
affaan-m/ECC