mcpField
D
domain-driven-design

domain-driven-design

github.com/sickn33Development49.2k221 installsUpdated 1d ago
Repository

About domain-driven-design

domain-driven-design is a skill for deciding whether and how to apply Domain-Driven Design to complex business domains. It guides teams through strategic artifacts, implementation patterns, and task-specific skills while cautioning against overuse for simple systems.

Key features

  1. 01Assess DDD viability before adoption
  2. 02Define subdomains and bounded contexts
  3. 03Connect strategic design to implementation
  4. 04Route work to specialized skills
  5. 05Specify stage outputs and open risks

Use cases

  1. 01Evaluating DDD for a complex business
  2. 02Planning boundaries across teams
  3. 03Choosing CQRS or event sourcing patterns
  4. 04Structuring domain-design deliverables

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill domain-driven-design

After installing, type/domain-driven-designin Claude Code to confirm it loaded.

Bundled filesreferences/ddd-deliverables.md

Details

From the project README

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

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

Markdown supported