Architecture 使用示例

# 架构示例 > 基于项目类型的真实世界架构决策。 --- ## 示例 1：MVP 电子商务（独立开发者） yaml 需求: - 初始用户 10K → 提取支付服务 - 团队 > 3人 → 添加 Repository 模式 - 需要社交登录 → 添加 OAuth --- ## 示例 2：SaaS 产品（5-10 名开发者） yaml 需求: - 1K-100K 用户 - 5-10 名开发者 - 长期项目 (12个月+) - 多领域 (计费、用户、核心) 架构决策: 应用结构: 模块化单体 (团队规模最优) 框架: NestJS (设计上模块化) 数据层: Repository 模式 (测试、灵活性) 领域模型: 部分 DDD (富实体) 认证: OAuth + JWT 缓存: Redis 数据库: PostgreSQL 接受的权衡: - 模块化单体 → 存在模块耦合 (微服务尚无必要) - 部分 DDD → 无完整聚合 (无领域专家) - RabbitMQ 稍后添加 → 初始同步 (证明需要时再添加) 迁移路径: - 团队 > 10人 → 考虑微服务 - 领域冲突 → 提取限界上下文 - 读取性能问题 → 添加 CQRS --- ## 示例 3：企业级应用（100K+ 用户） yaml 需求: - 100K+ 用户 - 10+ 开发者 - 多个业务领域 - 不同的扩展需求 - 24/7 可用性 架构决策: 应用结构: 微服务 (独立扩展) API 网关: Kong/AWS API GW 领域模型: 完整 DDD 一致性: 事件驱动 (最终一致性可接受) 消息总线: Kafka 认证: OAuth + SAML (企业级 SSO) 数据库: 多语言持久化 (Polyglot，因地制宜) CQRS: 部分服务使用 运维需求: - 服务网格 (Istio/Linkerd) - 分布式追踪 (Jaeger/Tempo) - 集中式日志 (ELK/Loki) - 断路器 (Resilience4j) - Kubernetes/Helm