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 → Identify subdomains and their strategic importance
- Bounded Context Definition → Draw boundaries where language changes
- Context Mapping → Define integration patterns between contexts
- Architecture Selection → Choose modular monolith vs microservices
- Tactical Implementation → Apply patterns within core domains only
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
- Anti-Patterns: See references/ANTI-PATTERNS.md for common pitfalls and how to avoid them
- 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
Implementation Skills
For framework-specific implementation of these patterns:
- Spring Boot data layer: See
spring-boot-data-ddd skill for JPA/JDBC aggregates, repositories, transactions
- Spring Boot web layer: See
spring-boot-web-api skill for controllers, validation, exception handling
- Spring Modulith: See
spring-boot-modulith skill for module structure and event-driven communication
These skills provide Spring Boot 4 implementation patterns for the DDD concepts defined here.
1---2name: domain-driven-design3description: 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.4---5
6# Domain-Driven Design Skill
7
8DDD manages complexity through alignment between software and business reality. **Strategic design (boundaries, language, subdomains) provides more value than tactical patterns (aggregates, repositories).**
9
10## When to Apply DDD
11
12**Apply DDD when:**
13- Domain has intricate business rules
14- System is long-lived and high-value
15- Domain experts are available
16- Multiple teams/departments involved
17- Software represents competitive advantage
18
19**DDD is overkill when:**
20- Simple CRUD applications
21- Tight deadlines, limited budgets
22- No domain experts available
23- Complexity is purely technical, not business
24
25## Core Workflow
26
271. **Domain Discovery** → Identify subdomains and their strategic importance
282. **Bounded Context Definition** → Draw boundaries where language changes
293. **Context Mapping** → Define integration patterns between contexts
304. **Architecture Selection** → Choose modular monolith vs microservices
315. **Tactical Implementation** → Apply patterns within core domains only
32
33## Quick Reference
34
35### Subdomain Types (Problem Space)
36
37| Type | Investment | Example |
38|------|-----------|---------|
39| **Core** | Maximum - competitive advantage | Recommendation engine, trading logic |
40| **Supporting** | Custom but quality tradeoffs OK | Inventory management |
41| **Generic** | Buy/outsource | Auth, email, payments |
42
43### Key Decision: Entity vs Value Object
44
45- **Entity**: Has identity, tracked through time, mutable → `Customer`, `Order`
46- **Value Object**: Defined by attributes, immutable, interchangeable → `Money`, `Address`, `Email`
47
48**Default to value objects.** Only use entities when identity matters.
49
50### Aggregate Design Rules (Vaughn Vernon)
51
521. Model true invariants in consistency boundaries
532. Design small aggregates (~70% should be root + value objects only)
543. Reference other aggregates by ID only
554. Use eventual consistency outside the boundary
56
57### Architecture Decision
58
59```
60Start with modular monolith when:
61├── Team < 20 developers
62├── Domain boundaries unclear
63├── Time-to-market critical
64└── Strong consistency required
65
66Consider microservices when:
67├── Bounded contexts have distinct languages
68├── Teams can own full contexts
69├── Independent scaling required
70└── DevOps maturity exists
71```
72
73## Detailed References
74
75- **Strategic Patterns**: See [references/STRATEGIC-PATTERNS.md](references/STRATEGIC-PATTERNS.md) for subdomains, bounded contexts, context mapping, event storming
76- **Tactical Patterns**: See [references/TACTICAL-PATTERNS.md](references/TACTICAL-PATTERNS.md) for entities, value objects, aggregates, services, repositories
77- **Architecture Alignment**: See [references/ARCHITECTURE-ALIGNMENT.md](references/ARCHITECTURE-ALIGNMENT.md) for clean/hexagonal architecture, modular monolith, microservices
78- **Anti-Patterns**: See [references/ANTI-PATTERNS.md](references/ANTI-PATTERNS.md) for common pitfalls and how to avoid them
79- **Troubleshooting**: See [TROUBLESHOOTING.md](TROUBLESHOOTING.md) for common issues and solutions
80
81## Critical Reminders
82
831. **Ubiquitous language first** - Code should read like business language
842. **Strategic before tactical** - Understand boundaries before implementing patterns
853. **Apply tactical patterns selectively** - Only in core domains where complexity warrants
864. **One aggregate per transaction** - Cross-aggregate consistency via domain events
875. **Persistence ignorance** - Domain layer has no infrastructure dependencies
88
89## Implementation Skills
90
91For framework-specific implementation of these patterns:
92
93- **Spring Boot data layer**: See `spring-boot-data-ddd` skill for JPA/JDBC aggregates, repositories, transactions
94- **Spring Boot web layer**: See `spring-boot-web-api` skill for controllers, validation, exception handling
95- **Spring Modulith**: See `spring-boot-modulith` skill for module structure and event-driven communication
96
97These skills provide Spring Boot 4 implementation patterns for the DDD concepts defined here.
majiayu000