评估变更方案验证决策：编制不必然比编排耦合更低

判断一个架构决策是否靠谱，光靠讨论当下的实现是不够的，要设想一个现实的变更场景、看它会牵连多少组件，这比单纯比较耦合”感觉上”孰高孰低更有说服力。书中给了一个用户入网流程的对照实验：项目团队最初凭”事件驱动耦合更低”的直觉（未经充分调研，更多基于私下讨论和个别人的偏好）设计了一条事件链——注册请求事件触发信用检查和地址检查两个服务，二者各自发布结果事件，用户服务等两个事件都到齐才创建用户。为了验证这个直觉，作者引入一个现实的变更需求：新增一项”犯罪记录检查”。在编制（事件链）版本里，除了要新增部署一个犯罪记录检查微服务，还必须调整并重新部署用户服务，让它多等一个新的事件；在编排版本里（用户微服务对注册请求事件做出反应，然后主动命令各检查服务完成工作），加一项检查同样需要新增部署检查服务、调整并重新部署用户服务——两种方案需要改动的服务数量完全一样，说明”事件驱动天然解耦更彻底”这个初始直觉是错的。真正的差异在别处：编排版本里有一个地方能让你清楚看到整个流程全貌，而编制版本里，这些流程知识分散在各个涉及的微服务中，没有任何单一位置能完整呈现。现实场景通常比这个例子更复杂——比如各项检查之间往往有顺序依赖（地址无效就不必再花钱做信用检查），越接近真实业务，改变一个事件流的执行顺序涉及的微服务数量往往越多、越难改。