荒野大集成：Ash的故事揭示的常见反模式

一个虚构但极具代表性的开发者故事：Ash负责一个信用卡收款后端，一开始只是简单调用外部信用卡服务的REST API；同事提醒该服务不稳定后，Ash加了重试逻辑；得知故障可能持续几小时后，Ash发现简单重试不够、需要状态处理和调度器，但先搁置；服务上线后因信用卡服务不可用而大量报错，CEO施压，Ash被迫自建payment表记录status字段、写了个每隔几秒轮询未支付记录的调度逻辑，API改成异步、返回HTTP 202、履约团队改为轮询查询支付状态；上线后又遇到调度器被一个异常打断而崩溃、大量订单堆积未处理，Ash手动修复并加了邮件告警脚本；最后业务方又提出SLA监控和可用性报告需求，迫使Ash继续给这个”临时拼凑”的系统添砖加瓦。这一路演化出的系统被称为荒野大集成——一种没有任何管理方案的临时集成方式，特点包括：通过数据库集成（服务直接读写其他服务的数据库，对方毫不知情）、简单的点对点集成（组件间直连但未充分描述远程通信的所有细节）、数据库触发器（写入数据库时自动触发其他逻辑）、脆弱的工具链（如用FTP传CSV文件）。Ash耗费大量精力手写的代码——维持当前状态、调度重试、报告当前状态、操作长期运行的流程——本质上正是工作流引擎的内置功能：与其自己一点点摸索重新发明，不如直接用现成工具。不用工作流引擎写流程，通常会让代码变复杂，状态处理最终和组件本身耦合，业务逻辑和业务流程的实现因此更难理解；沿着Ash这条路走下去，很容易一步步演变成一个自研工作流引擎——这带来更多研发维护成本，却还没有现成工具的优势。