软件架构判断训练场

场景: 团队决定用 MongoDB 做主数据库，ADR 只写了一句话："因为数据模型灵活，选 MongoDB。" 没有上下文、没有候选方案、没有约束分析。

问题:
· 这个 ADR 缺了什么关键信息？
· 它应该记录哪些被拒绝的方案及理由？
· 如果一年后你们发现 MongoDB 的事务支持和 JOIN 需求不满足，这个 ADR 能帮后人判断当时的取舍吗？

回读路径: 架构决策与评审 → ADR 模板和好 ADR 的标准

场景: 你做了一次架构评审，方案是用 Kafka 做服务间同步调用（A 发消息等 B 回复）。方案说"Kafka 吞吐高，所以适合"。团队 3 个人，系统初期日活 1000 用户。

问题:
· 评审中最应该质疑的三个问题是什么？
· 约束条件（团队规模、业务阶段）没有进入判断会有什么后果？
· 怎样判断这个方案是"技术上没错但现阶段不适合"？

回读路径: 架构决策与评审 → 评审机制、约束分析

场景: 你要为 AI Agent 平台选主编程语言。团队熟悉 Java 和 Python。候选方案：Python（团队能写但缺后端基础设施）、Java（后端成熟但 ML 生态弱）、Go（性能好但团队要学）。

问题:
· 这个决策的约束条件有哪些（团队、时间、生态、运维）？
· 哪些约束是可改变的，哪些是不可改变的？
· 你会选哪个方案？记录你的取舍理由。

回读路径: 架构决策与评审 → 决策因素、候选方案评估

场景: 一个电商后台，团队 6 人。方案 A：拆成 8 个微服务（用户、商品、订单、支付、库存、物流、营销、通知）。方案 B：先落地 3 个模块（订单、商品、用户）在一个部署单元内，后续看边界稳定性再拆。

问题:
· 方案 A 和 B 各自的成本和收益是什么？
· 怎么判断一个服务边界"拆对了"？
· 方案 A 在 6 人团队下会出什么问题？
· 什么条件下方案 A 才是合理选择？

回读路径: 设计路线 → 模块与服务设计层

场景: 你们把"用户管理"和"权限管理"拆成两个服务。结果每次新建角色都要调两次 API（用户服务 + 权限服务），而且大量场景需要同时查询用户信息和权限信息。调用方开始抱怨延迟高。

问题:
· 边界划错的判断标准是什么？
· 现在有哪些修复方案（合并、加缓存、批量接口…）？
· 怎样判断哪种修复方案在这个场景下最优？

回读路径: 设计路线 → 系统边界与核心对象层

场景: 团队在讨论要不要引入 DDD（领域驱动设计）。一部分人说"DDD 太重，小项目不需要"；另一部分说"不用 DDD 后面一定会乱"。

问题:
· DDD 的哪些部分（战略设计 vs 战术设计）在小项目中有价值？
· 怎么判断当前项目的复杂度是否需要 DDD？
· "先不落地 DDD"和"错误落地 DDD"哪个代价更大？

回读路径: DDD 书页 · 实现 DDD 书页

场景: 服务 A 要和服务 B 通信，场景是批量查询订单状态（每次 100-1000 个订单，实时返回）。服务 A 是前端 BFF，服务 B 是订单服务。

问题:
· REST 和 gRPC 在这个场景下的优劣分别是什么？
· 如果网络环境差（跨机房），选型会不会变？
· 如果以后要开放给第三方调用，选型会不会变？

回读路径: API 与系统集成 → API 风格选型

场景: 你们的订单 API 已经发布了 v1，现在要改响应字段（删一个字段、加两个字段、改一个字段名）。你有 30 个外部调用方。

问题:
· 删字段、加字段、改字段名，这三种变化的兼容性策略分别怎么做？
· 什么时候该发新版本 vs 向后兼容？
· 不通如所有调用方就改字段名会发生什么？

回读路径: API 与系统集成 → 版本策略 · API 生命周期

场景: 用户服务用 Kafka 发布 UserCreated 事件。消费方有 5 个服务。现在要在事件中增加一个 phone 字段，但有些消费方的 Schema 校验会拒绝未知字段。

问题:
· 加字段是向前兼容还是向后兼容的变化？
· 怎么在不中断所有消费方的情况下完成这个变更？
· 如果必须同时改生产和消费方，怎么安排发布顺序？

回读路径: 数据契约 → Schema 兼容性策略

场景: 检查以下项目：①"下单后 3 秒才返回，但业务目前可接受"；②"用户表和订单表在同一个库里"；③"日志打到了 console 而不是 ELK"；④"if-else 分支超过 50 个"。

问题:
· 哪几项属于架构债？
· 哪几项只是代码债或运维债？
· "目前可接受"是推迟还债的合理理由还是自我欺骗？

回读路径: 架构债 → 债的分类和判断标准

场景: 你有一个 3 人团队维护遗留系统。当前有：①数据库在主从复制延迟下经常读到脏数据（影响用户体验）；②代码里大量复制粘贴（维护成本高但不影响用户）；③缺少单元测试覆盖率（每次改代码都手动测）。

问题:
· 优先级怎么排？你的判断标准是什么？
· 哪些债"不还也能运行"，哪些债"不还会越来越严重"？
· 如果产品经理给了一个紧急新功能，怎么优雅拒绝？

回读路径: 架构债 → 优先级和偿还策略

场景: 公司说"要加强架构治理"，方案是：①所有接口变更都要审批；②每周开一次架构委员会；③所有新项目必须画 C4 图才能立项。

问题:
· 这套方案的核心问题是什么？
· 如果改成"只审批不可逆的决策"，哪些决策是不可逆的？
· 怎么判断一个治理规则是在帮助团队还是在拖慢团队？

回读路径: 架构决策与评审 → 评审机制、治理边界

场景: 用户下单后调用支付网关，支付网关返回超时（但实际已扣款）。你的系统需要决定：是"重试支付"还是"不重��"？

问题:
· 幂等键在这个场景里怎么用？
· 如果支付网关不支持幂等，还有什么方案？
· 对账机制在什么时间窗口内可以发现这个不一致？

回读路径: 补偿、对账与重放

场景: 你用 Saga 编排模式实现下单流程（创建订单 → 扣库存 → 扣款 → 发货）。扣款成功了但发货失败，补偿动作是退单+退款+加库存。然而退款也失败了。

问题:
· 补偿失败时系统应该停在什么状态？
· 人工介入的触发条件是什么？
· 对账机制在这里能扮演什么角色？

回读路径: 补偿、对账与重放 → Saga 补偿策略