7edf5bc4d0
Major updates: - Added 35+ new skills from awesome-opencode-skills and antigravity repos - Merged SEO skills into seo-master - Merged architecture skills into architecture - Merged security skills into security-auditor and security-coder - Merged testing skills into testing-master and testing-patterns - Merged pentesting skills into pentesting - Renamed website-creator to thai-frontend-dev - Replaced skill-creator with github version - Removed Chutes references (use MiniMax API instead) - Added install-openclaw-skills.sh for cross-platform installation - Updated .env.example with MiniMax API credentials
2.6 KiB
2.6 KiB
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)
- Problem Solved: What SPECIFIC problem does this pattern solve?
- Simpler Alternative: Is there a simpler solution?
- 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 |