Domain-Driven Design Skill
DDD manages complexity through alignment between software and business reality. Strategic design (boundaries, language, subdomains) provides more value than tactical patterns (aggregates, repositories).
When to Apply DDD
Apply DDD when:
- Domain has intricate business rules
- System is long-lived and high-value
- Domain experts are available
- Multiple teams/departments involved
- Software represents competitive advantage
DDD is overkill when:
- Simple CRUD applications
- Tight deadlines, limited budgets
- No domain experts available
- Complexity is purely technical, not business
Core Workflow
- Domain Discovery → 2. Bounded Context Definition → 3. Context Mapping → 4. Architecture Selection → 5. Tactical Implementation
See WORKFLOW.md for detailed step-by-step instructions for each phase.
Quick Reference
Subdomain Types (Problem Space)
| Type |
Investment |
Example |
| Core |
Maximum - competitive advantage |
Recommendation engine, trading logic |
| Supporting |
Custom but quality tradeoffs OK |
Inventory management |
| Generic |
Buy/outsource |
Auth, email, payments |
Key Decision: Entity vs Value Object
- Entity: Has identity, tracked through time, mutable →
Customer, Order
- Value Object: Defined by attributes, immutable, interchangeable →
Money, Address, Email
Default to value objects. Only use entities when identity matters.
Aggregate Design Rules (Vaughn Vernon)
- Model true invariants in consistency boundaries
- Design small aggregates (~70% should be root + value objects only)
- Reference other aggregates by ID only
- Use eventual consistency outside the boundary
Architecture Decision
Start with modular monolith when:
├── Team < 20 developers
├── Domain boundaries unclear
├── Time-to-market critical
└── Strong consistency required
Consider microservices when:
├── Bounded contexts have distinct languages
├── Teams can own full contexts
├── Independent scaling required
└── DevOps maturity exists
Detailed References
- Strategic Patterns: See references/STRATEGIC-PATTERNS.md for subdomains, bounded contexts, context mapping, event storming
- Tactical Patterns: See references/TACTICAL-PATTERNS.md for entities, value objects, aggregates, services, repositories
- Architecture Alignment: See references/ARCHITECTURE-ALIGNMENT.md for clean/hexagonal architecture, modular monolith, microservices
- Workflow: See WORKFLOW.md for detailed step-by-step DDD implementation process
- Anti-Patterns: See references/ANTI-PATTERNS.md for common pitfalls and how to avoid them
- Examples: See EXAMPLES.md for scenario walkthroughs applying DDD concepts
- Troubleshooting: See TROUBLESHOOTING.md for common issues and solutions
Critical Reminders
- Ubiquitous language first - Code should read like business language
- Strategic before tactical - Understand boundaries before implementing patterns
- Apply tactical patterns selectively - Only in core domains where complexity warrants
- One aggregate per transaction - Cross-aggregate consistency via domain events
- Persistence ignorance - Domain layer has no infrastructure dependencies
Related Skills
| Need |
Skill |
| Data layer implementation |
spring-boot-data-ddd — JPA/JDBC aggregates, repositories, transactions |
| REST API layer |
spring-boot-web-api — Controllers, validation, exception handling |
| Module boundaries |
spring-boot-modulith — Module structure, event-driven communication |
| Testing patterns |
spring-boot-testing — Aggregate tests, module tests, Scenario API |
| Security for domains |
spring-boot-security — Method-level authorization, role-based access |
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: domain-driven-design-63description: Expert guidance for Domain-Driven Design architecture and implementation. Use when designing complex business systems, defining bounded contexts, structuring domain models, choosing between modular monolith vs microservices, implementing aggregates/entities/value objects, or when users mention "DDD", "domain-driven design", "bounded context", "aggregate", "domain model", "ubiquitous language", "event storming", "context mapping", "domain events", "anemic domain model", strategic design, tactical patterns, or domain modeling. Helps make architectural decisions, identify subdomains, design aggregates, and avoid common DDD pitfalls. Use when this capability is needed.4---56# Domain-Driven Design Skill78DDD manages complexity through alignment between software and business reality. **Strategic design (boundaries, language, subdomains) provides more value than tactical patterns (aggregates, repositories).**910## When to Apply DDD1112**Apply DDD when:**13- Domain has intricate business rules14- System is long-lived and high-value15- Domain experts are available16- Multiple teams/departments involved17- Software represents competitive advantage1819**DDD is overkill when:**20- Simple CRUD applications21- Tight deadlines, limited budgets22- No domain experts available23- Complexity is purely technical, not business2425## Core Workflow26271. Domain Discovery → 2. Bounded Context Definition → 3. Context Mapping → 4. Architecture Selection → 5. Tactical Implementation2829See [WORKFLOW.md](WORKFLOW.md) for detailed step-by-step instructions for each phase.3031## Quick Reference3233### Subdomain Types (Problem Space)3435| Type | Investment | Example |36|------|-----------|---------|37| **Core** | Maximum - competitive advantage | Recommendation engine, trading logic |38| **Supporting** | Custom but quality tradeoffs OK | Inventory management |39| **Generic** | Buy/outsource | Auth, email, payments |4041### Key Decision: Entity vs Value Object4243- **Entity**: Has identity, tracked through time, mutable → `Customer`, `Order`44- **Value Object**: Defined by attributes, immutable, interchangeable → `Money`, `Address`, `Email`4546**Default to value objects.** Only use entities when identity matters.4748### Aggregate Design Rules (Vaughn Vernon)49501. Model true invariants in consistency boundaries512. Design small aggregates (~70% should be root + value objects only)523. Reference other aggregates by ID only534. Use eventual consistency outside the boundary5455### Architecture Decision5657```58Start with modular monolith when:59├── Team < 20 developers60├── Domain boundaries unclear61├── Time-to-market critical62└── Strong consistency required6364Consider microservices when:65├── Bounded contexts have distinct languages66├── Teams can own full contexts67├── Independent scaling required68└── DevOps maturity exists69```7071## Detailed References7273- **Strategic Patterns**: See [references/STRATEGIC-PATTERNS.md](references/STRATEGIC-PATTERNS.md) for subdomains, bounded contexts, context mapping, event storming74- **Tactical Patterns**: See [references/TACTICAL-PATTERNS.md](references/TACTICAL-PATTERNS.md) for entities, value objects, aggregates, services, repositories75- **Architecture Alignment**: See [references/ARCHITECTURE-ALIGNMENT.md](references/ARCHITECTURE-ALIGNMENT.md) for clean/hexagonal architecture, modular monolith, microservices76- **Workflow**: See [WORKFLOW.md](WORKFLOW.md) for detailed step-by-step DDD implementation process77- **Anti-Patterns**: See [references/ANTI-PATTERNS.md](references/ANTI-PATTERNS.md) for common pitfalls and how to avoid them78- **Examples**: See [EXAMPLES.md](EXAMPLES.md) for scenario walkthroughs applying DDD concepts79- **Troubleshooting**: See [TROUBLESHOOTING.md](TROUBLESHOOTING.md) for common issues and solutions8081## Critical Reminders82831. **Ubiquitous language first** - Code should read like business language842. **Strategic before tactical** - Understand boundaries before implementing patterns853. **Apply tactical patterns selectively** - Only in core domains where complexity warrants864. **One aggregate per transaction** - Cross-aggregate consistency via domain events875. **Persistence ignorance** - Domain layer has no infrastructure dependencies8889## Related Skills9091| Need | Skill |92|------|-------|93| Data layer implementation | `spring-boot-data-ddd` — JPA/JDBC aggregates, repositories, transactions |94| REST API layer | `spring-boot-web-api` — Controllers, validation, exception handling |95| Module boundaries | `spring-boot-modulith` — Module structure, event-driven communication |96| Testing patterns | `spring-boot-testing` — Aggregate tests, module tests, Scenario API |97| Security for domains | `spring-boot-security` — Method-level authorization, role-based access |9899---100> Converted and distributed by [TomeVault](https://tomevault.io/claim/joaquimscosta) — claim your Tome and manage your conversions.101<!-- tomevault:4.0:skill_md:2026-04-12 -->
tomevault-io