Domain Driven Design

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