# Pattern Selection Guidelines
> Decision trees for choosing architectural patterns.
## Main Decision Tree
```
START: What's your MAIN concern?
┌─ Data Access Complexity?
│ ├─ HIGH (complex queries, testing needed)
│ │ → Repository Pattern + Unit of Work
│ │ VALIDATE: Will data source change frequently?
│ │ ├─ YES → Repository worth the indirection
│ │ └─ NO → Consider simpler ORM direct access
│ └─ LOW (simple CRUD, single database)
│ → ORM directly (Prisma, Drizzle)
│ Simpler = Better, Faster
│
├─ Business Rules Complexity?
│ ├─ HIGH (domain logic, rules vary by context)
│ │ → Domain-Driven Design
│ │ VALIDATE: Do you have domain experts on team?
│ │ ├─ YES → Full DDD (Aggregates, Value Objects)
│ │ └─ NO → Partial DDD (rich entities, clear boundaries)
│ └─ LOW (mostly CRUD, simple validation)
│ → Transaction Script pattern
│ Simpler = Better, Faster
│
├─ Independent Scaling Needed?
│ ├─ YES (different components scale differently)
│ │ → Microservices WORTH the complexity
│ │ REQUIREMENTS (ALL must be true):
│ │ - Clear domain boundaries
│ │ - Team > 10 developers
│ │ - Different scaling needs per service
│ │ IF NOT ALL MET → Modular Monolith instead
│ └─ NO (everything scales together)
│ → Modular Monolith
│ Can extract services later when proven needed
│
└─ Real-time Requirements?
├─ HIGH (immediate updates, multi-user sync)
│ → Event-Driven Architecture
│ → Message Queue (RabbitMQ, Redis, Kafka)
│ VALIDATE: Can you handle eventual consistency?
│ ├─ YES → Event-driven valid
│ └─ NO → Synchronous with polling
└─ LOW (eventual consistency acceptable)
→ Synchronous (REST/GraphQL)
Simpler = Better, Faster
```
## The 3 Questions (Before ANY Pattern)
1. **Problem Solved**: What SPECIFIC problem does this pattern solve?
2. **Simpler Alternative**: Is there a simpler solution?
3. **Deferred Complexity**: Can we add this LATER when needed?
## Red Flags (Anti-patterns)
| Pattern | Anti-pattern | Simpler Alternative |
|---------|-------------|-------------------|
| Microservices | Premature splitting | Start monolith, extract later |
| Clean/Hexagonal | Over-abstraction | Concrete first, interfaces later |
| Event Sourcing | Over-engineering | Append-only audit log |
| CQRS | Unnecessary complexity | Single model |
| Repository | YAGNI for simple CRUD | ORM direct access |
