业务反应与技术反应：比"业务错误/技术错误"更实用的分类框架

延续[[区分结果异常和错误网关处理预期结果错误事件处理异常]]的讨论，”业务错误”和”技术错误”这两个常见术语其实容易引发争论且并不好用，因为它们把注意力放在了”错误的来源是什么”上——某个问题到底算不算技术性的、技术错误是否该出现在业务流程模型里，这类争论可以没完没了地进行下去。更关键的其实是”你如何对某个错误做出反应”：即使一个问题的根源明显是技术性的（比如评分服务暂时不可用），对它的应对方式完全可以是一个业务决策——例如决定在评分服务不可用时不阻塞整个流程，而是简单给每个客户一个默认的好评价、让流程继续走下去。基于这个洞见，作者更推荐谈论”业务反应”（business reaction）和”技术反应”（technical reaction）而不是”业务错误/技术错误”：业务反应应该被建模进流程本身（因为它是需要被所有人看见、理解和讨论的业务决策），技术反应则在工具层面处理，比如运维过程里配置的重试或事件响应，默认不出现在可视化图形里。一个具体的组合场景：评分服务不可用时先触发一个技术反应（自动重试），但如果这个技术性问题持续一段时间没解决，就会升级为一个业务反应——因为持续不可用可能会影响评分服务本应遵守的某些SLA，这时就必须在流程模型里让所有人看见并做出业务层面的应对决策，而不能继续隐藏在纯技术重试逻辑背后。