domain-driven-design

Topics in the source

• Domain-Driven Design
• Use this skill when
• Do not use this skill when
• Instructions
• Viability check
• Routing map
• Output requirements
• Examples

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. 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. 1. Run a viability check before committing to full DDD. 2. Produce strategic artifacts first: subdomains, bounded contexts, language glossary. 3. Route to specialized skills based on current task. 4. Define success criteria and evidence for each stage. 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. 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-arc

This is an excerpt. Refer to the complete source and its current requirements.