domain-driven-design

# 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

1. **Domain Discovery** → Identify subdomains and their strategic importance
2. **Bounded Context Definition** → Draw boundaries where language changes
3. **Context Mapping** → Define integration patterns between contexts
4. **Architecture Selection** → Choose modular monolith vs microservices
5. **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)

1. Model true invariants in consistency boundaries
2. Design small aggregates (~70% should be root + value objects only)
3. Reference other aggregates by ID only
4. Use eventual consistency outside the boundary

### Architecture Decision

```
Start with modular monolith when:
├── Team < 20 develope