Domain Driven Design

1---
2name: domain-driven-design
3description: Plan and route Domain-Driven Design work from strategic modeling to tactical implementation and evented architecture patterns.
4risk: safe
5source: self
6tags: [ddd, domain, bounded-context, architecture]
7---
8 
9# Domain-Driven Design
10 
11## Use this skill when
12 
13- You need to model a complex business domain with explicit boundaries.
14- You want to decide whether full DDD is worth the added complexity.
15- You need to connect strategic design decisions to implementation patterns.
16- You are planning CQRS, event sourcing, sagas, or projections from domain needs.
17 
18## Do not use this skill when
19 
20- The problem is simple CRUD with low business complexity.
21- You only need localized bug fixes.
22- There is no access to domain knowledge and no proxy product expert.
23 
24## Instructions
25 
261. Run a viability check before committing to full DDD.
272. Produce strategic artifacts first: subdomains, bounded contexts, language glossary.
283. Route to specialized skills based on current task.
294. Define success criteria and evidence for each stage.
30 
31### Viability check
32 
33Use full DDD only when at least two of these are true:
34 
35- Business rules are complex or fast-changing.
36- Multiple teams are causing model collisions.
37- Integration contracts are unstable.
38- Auditability and explicit invariants are critical.
39 
40### Routing map
41 
42- Strategic model and boundaries: `@ddd-strategic-design`
43- Cross-context integrations and translation: `@ddd-context-mapping`
44- Tactical code modeling: `@ddd-tactical-patterns`
45- Read/write separation: `@cqrs-implementation`
46- Event history as source of truth: `@event-sourcing-architect` and `@event-store-design`
47- Long-running workflows: `@saga-orchestration`
48- Read models: `@projection-patterns`
49- Decision log: `@architecture-decision-records`
50 
51If templates are needed, open `references/ddd-deliverables.md`.
52 
53## Output requirements
54 
55Always return:
56 
57- Scope and assumptions
58- Current stage (strategic, tactical, or evented)
59- Explicit artifacts produced
60- Open risks and next step recommendation
61 
62## Examples
63 
64```text
65Use @domain-driven-design to assess if this billing platform should adopt full DDD.
66Then route to the right next skill and list artifacts we must produce this week.
67```
68 
69## Limitations
70 
71- This skill does not replace direct workshops with domain experts.
72- It does not provide framework-specific code generation.
73- It should not be used as a justification to over-engineer simple systems.
74