pattern-selection

# 模式选择指南 > 选择架构模式的决策树。 ## 主决策树 开始：你最主要的关注点是什么？ ┌─ 数据访问复杂度？ │ ├─ 高 (复杂查询，需要测试) │ │ → Repository 模式 + 工作单元 (Unit of Work) │ │ 验证：数据源会频繁变更吗？ │ │ ├─ 是 → Repository 值得引入间接层 │ │ └─ 否 → 考虑更简单的 ORM 直接访问 │ └─ 低 (简单 CRUD，单数据库) │ → 直接使用 ORM (Prisma, Drizzle) │ 越简单 = 越好，越快 │ ├─ 业务规则复杂度？ │ ├─ 高 (领域逻辑，规则随上下文变化) │ │ → 领域驱动设计 (DDD) │ │ 验证：团队中有领域专家吗？ │ │ ├─ 是 → 完整 DDD (聚合、值对象) │ │ └─ 否 → 部分 DDD (富实体，清晰边界) │ └─ 低 (主要是 CRUD，简单验证) │ → 事务脚本模式 (Transaction Script) │ 越简单 = 越好，越快 │ ├─ 需要独立扩展？ │ ├─ 是 (不同组件扩展需求不同) │ │ → 微服务 (值得其复杂性) │ │ 要求 (必须全部满足)： │ │ - 清晰的领域边界 │ │ - 团队 > 10 名开发者 │ │ - 不同服务有不同的扩展需求 │ │ 如果未全部满足 → 改用模块化单体 │ └─ 否 (所有组件一起扩展) │ → 模块化单体 │ 证明需要时后续可提取服务 │ └─ 实时性要求？ ├─ 高 (即时更新，多用户同步) │ → 事件驱动架构 │ → 消息队列 (RabbitMQ, Redis, Kafka) │ 验证：你能处理最终一致性吗？ │ ├─ 是 → 事件驱动有效 │ └─ 否 → 同步轮询 └─ 低 (最终一致性可接受) → 同步 (REST/GraphQL) 越简单 = 越好，越快 ## 3 个问题（在选择任何模式之前） 1. **解决的问题**：该模式具体解决了什么问题？ 2. **更简单的替代方案**：是否有更简单的解决方案？ 3. **延迟复杂性**：我们可以在需要时稍后再添加吗？ ## 危险信号（反模式） | 模式 | 反模式 | 更简单的替代方案 | |---------|-------------|-------------------| | 微服务 | 过早拆分 | 从单体开始，后续提取 | | 整洁/六边形架构 | 过度抽象 | 先具体实现，后接口 | | 事件溯源 | 过度工程 | 仅追加审计日志 | | CQRS | 不必要的复杂性 | 单一模型 | | Repository | 简单 CRUD 的 YAGNI | ORM 直接访问 |