Skill

domain-driven-design

Orchestrates Domain-Driven Design: viability checks, strategic modeling (subdomains, bounded contexts), and routes to tactical patterns like CQRS, event sourcing, sagas.

backend

npx claudepluginhub mit-network/antigravity-awesome-skills

Tool Access

This skill uses the workspace's default tool permissions.

Preview

- You need to model a complex business domain with explicit boundaries.

Supporting Assets

references/ddd-deliverables.md

SKILL.md

Similar Skills

domain-driven-design

36.4k

Orchestrates Domain-Driven Design: viability checks, strategic modeling (subdomains, bounded contexts), and routes to tactical patterns like CQRS, event sourcing, sagas.

1 file

antigravity-awesome-skills

ddd

Guides Domain-Driven Design workflows: domain discovery, ubiquitous language, event storming, bounded contexts, aggregates, entities, value objects, domain events, repositories. For complex business logic beyond CRUD.

godmode

domain-driven-design

744

Applies Domain-Driven Design to model software around business domains using bounded contexts, aggregates, ubiquitous language, domain events, and context mapping. For domain modeling, monolith splitting, and microservice boundaries.

6 files

code-craftsmanship

Stats

Stars1

Forks0

Last CommitFeb 27, 2026

Used By9 plugins

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

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-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.