长期运行能力捍卫边界：烫手山芋反模式与API污染

[[荒野大集成Ash的故事揭示的常见反模式]]中提到的支付服务与脆弱信用卡服务通信的例子在这里给出了新解释：如果支付服务本身不存储任何状态，一旦调用信用卡服务出问题，它唯一能做的就是把问题原样甩回给上游调用方（这里是订单履约服务）——这就是”烫手山芋”反模式，面对问题只想着尽快脱手。这个反模式真正的代价不是”多转发了一次错误”，而是让支付服务的内部概念（比如”信用卡不可用”这种支付服务实现细节）泄漏进了对外API，最终一路嵌入到调用方的客户端代码里，两个服务因此被迫产生了额外的耦合。如果支付服务本身支持长期运行（比如通过工作流引擎实现状态持久化、能等待用户重新输入正确的支付信息），它就能对外提供一个极简的API——只告诉调用方”支付通过”或”支付失败”，把处理信用卡失败、等待用户补充信息等内部细节完全封装在自己边界内，不需要客户端插手。这类需求有时还直接来自业务本身，例如信用卡过期或被锁定导致扣费失败时，业务方希望能主动通知客户、要求提供新的支付信息，尤其是自动续订这种客户无需在线操作、系统需要自主处理支付信息更新的场景——这同样要求支付服务具备长期运行的能力。缺少长期运行能力，服务就很难满足这类需求，只能让内部概念混入API、增加服务间耦合；引入工作流引擎正是降低这种风险、帮你切实捍卫服务边界的一种简单实现方式。