4e8e5069fa
- Added: api-patterns, app-builder, architecture, bash-linux, behavioral-modes, clean-code, code-review-checklist, database-design, deployment-procedures, docker-expert, documentation-templates, game-development, geo-fundamentals, i18n-localization, lint-and-validate, mobile-design, nestjs-expert, nextjs-best-practices, nodejs-best-practices, parallel-agents, performance-profiling, plan-writing, powershell-windows, prisma-expert, python-patterns, react-patterns, red-team-tactics, seo-fundamentals, server-management, tailwind-patterns, tdd-workflow, typescript-expert, vulnerability-scanner - Updated README: skill count 179 → 223 - Added credit for vudovn/antigravity-kit (MIT License) Source: https://github.com/vudovn/antigravity-kit
69 lines
2.6 KiB
Markdown
69 lines
2.6 KiB
Markdown
# 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 |
|