techwavedev Domain-Driven Design
Use this skill when
- 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.
Do not use this skill when
- 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.
Instructions
- Run a viability check before committing to full DDD.
- Produce strategic artifacts first: subdomains, bounded contexts, language glossary.
- Route to specialized skills based on current task.
- Define success criteria and evidence for each stage.
Viability check
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.
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-architectand@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.
AGI Framework Integration
Adapted for @techwavedev/agi-agent-kit Original source: antigravity-awesome-skills
Memory-First Protocol
Retrieve prior Architecture Decision Records (ADRs), trade-off analyses, and system design rationale. Critical for maintaining consistency across long-running projects.
# Check for prior architecture/design context before starting
python3 execution/memory_manager.py auto --query "architecture decisions and trade-off analysis for Domain Driven Design"
Storing Results
After completing work, store architecture/design decisions for future sessions:
python3 execution/memory_manager.py store \
--content "Architecture: event-driven microservices with CQRS, Pulsar for messaging, Qdrant for semantic search" \
--type decision --project <project> \
--tags domain-driven-design architecture
Multi-Agent Collaboration
Broadcast architecture decisions to ALL agents so implementation stays aligned with the chosen patterns.
python3 execution/cross_agent_context.py store \
--agent "<your-agent>" \
--action "Completed architecture review — ADR documented, trade-offs analyzed, team aligned" \
--project <project>
Control Tower Coordination
Register architecture tasks in the Control Tower so all agents across machines know the current system design and constraints.