Assess and Apply Domain-Driven Design

Domain-Driven Design is a planning and routing skill for Domain-Driven Design work. It takes a team from strategic modeling through tactical implementation to evented architecture patterns. Rather than generating framework code, it decides whether full DDD is justified, produces the strategic artifacts first, and routes each part of the work to a specialized skill.

The instructions have four steps: run a viability check before committing to full DDD; produce strategic artifacts first (subdomains, bounded contexts and a language glossary); route to specialized skills based on the current task; and define success criteria and evidence for each stage.

The viability check is a concrete rule. 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, or auditability and explicit invariants are critical.

The routing map sends work to these companion skills:

• ddd-strategic-design for the strategic model and boundaries.
• ddd-context-mapping for cross-context integrations and translation.
• ddd-tactical-patterns for tactical code modeling.
• cqrs-implementation for read and write separation.
• event-sourcing-architect and event-store-design for event history as the source of truth.
• saga-orchestration for long-running workflows.
• projection-patterns for read models.
• architecture-decision-records for the decision log.

A bundled deliverables checklist keeps adoption practical and measurable. Strategic deliverables are a subdomain map (core, supporting, generic), a bounded context map with ownership, a ubiquitous language glossary and one or two ADRs documenting critical boundary decisions. Tactical deliverables are an aggregate list with invariants, a value object list, a domain events list, and repository contracts with transaction boundaries. Evented deliverables apply only when required: the rationale for command and query separation, an event schema versioning policy, a saga compensation matrix and a projection rebuild strategy.

An example prompt from the skill:

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.

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 decisions to implementation patterns, or plan CQRS, event sourcing, sagas or projections from domain needs.

Do not use it when the problem is simple CRUD with low business complexity, when you only need localized bug fixes, or when there is no access to domain knowledge and no proxy product expert. The skill lists its own limits: it does not replace direct workshops with domain experts, it does not provide framework-specific code generation, and it should not be used as a justification to over-engineer simple systems.

The input is a system or business domain to assess, together with access to domain knowledge or a proxy product expert. The skill always returns four things: scope and assumptions, the current stage (strategic, tactical or evented), the explicit artifacts produced, and open risks with a next step recommendation.

Teams working on complex business domains who need to decide how much DDD to adopt and which artifacts to produce at each stage.