| name | internal-ddd |
| description | Use when deciding whether a complex domain needs Domain-Driven Design, framing the current DDD stage from strategic modeling through tactical and evented patterns, and producing only the artifacts justified by real domain pressure. |
Internal DDD
Use this skill to decide how much Domain-Driven Design a problem deserves, then produce only the artifacts needed for the current stage and the next adjacent lane.
When to use
- Complex or fast-changing business rules are colliding with implementation structure.
- Teams or services are disagreeing on terms, ownership, or domain boundaries.
- Integration seams are unstable and the domain language is drifting between contexts.
- Auditability, invariants, or workflow coordination make tactical or evented modeling worth evaluating.
When not to use
- Simple CRUD with stable rules and obvious ownership.
- Localized bug fixes, isolated refactors, or framework-only questions.
- Cases where no domain knowledge or proxy product expertise is available.
Workflow
- Run a DDD viability check.
Confirm at least two signals: domain volatility, model collisions, unstable boundaries, or critical invariants.
- Start with the strategic frame unless the boundaries are already stable.
Name subdomains, bounded contexts, language, and translation seams before escalating into tactical or evented modeling.
- Choose the working mode.
Use strategic mode for subdomains and bounded contexts, tactical mode for aggregates and invariants, and evented mode only when integration or workflow pressure justifies it.
- Produce only the smallest useful artifact set.
Avoid generating strategic, tactical, and evented deliverables all at once.
- Record evidence, success criteria, and the next owner.
End with what was decided, what remains risky, and which adjacent skill or engineering lane should act next.
Working modes
- Strategic: subdomain map, bounded contexts, ubiquitous language, boundary ADRs, and cross-context translation seams.
- Tactical: aggregates, value objects, domain services, repository contracts, and invariants inside a stable bounded context.
- Evented: commands, domain events, read models or projections, CQRS rationale, saga boundaries, and rebuild or versioning policy.
Pressure map
- Boundary and terminology collisions: stay strategic until context ownership and translation seams are explicit.
- Weak invariants inside one context: use tactical modeling to decide aggregate boundaries, value objects, and enforcement homes.
- Read-write separation, read models, or long-running workflows: treat them as evented candidates only when operational pressure is explicit.
- Event history as source of truth: justify it separately from general event publication; it is a higher-cost choice than simple domain events.
Adjacent lanes
- Treat infrastructure boundaries as legitimate bounded-context candidates when the real seams are module ownership, environment contracts, or repo-level responsibility lines rather than object-oriented code.
- Keep evented design inside this skill until the rationale, ownership, and operational cost are explicit enough to hand off safely.
References
- Load
references/mode-selection.md when deciding whether the work is strategic, tactical, or evented.
- Load
references/ddd-deliverables.md when you need the concrete artifact checklist and exit criteria.
Output requirements
Always return:
- domain pressure and assumptions
- selected DDD mode and why
- artifacts produced or required next
- success criteria or evidence captured for the current stage
- explicit anti-overengineering note when DDD is not justified
- open risks and next recommended lane
Guardrails
- Do not present this skill as a router; it is a decision and artifact workflow.
- Do not recommend CQRS, event sourcing, or sagas without a clear pressure from workflow complexity or integration boundaries.
- Do not recommend read-write separation, event history as source of truth, or read models unless the operational reason is explicit.
- Do not let DDD vocabulary replace concrete domain terms.
