P公司与W公司的悲伤故事：草率架构决策的真实代价

[[边界的作用是推迟不成熟决策最耗人力的是过早决策导致的耦合]]的反例最有说服力。P公司原本是个成功的单体桌面应用，90年代末为了Web化雇了一批年轻Java程序员，这批人不假思索地设计了一套三层富架构：所有领域对象在GUI层、中间件层、数据库层各存一份实例，跨层通信要把函数调用转成对象、序列化、编码、网络传输——结果给现有记录加一个字段这么简单的需求，就要同步修改三层的类、设计四个双向传输协议、实现八个协议处理函数，还要处理这些新对象的初始化、序列化、编码解码、消息构建解析、socket通信、超时重试。最讽刺的是，P公司从来没卖出过一套真正需要服务器集群的系统——所有部署过的系统都只在一台机器上运行，却始终背负着这套本该服务于集群、但集群从未存在过的沉重架构，程序员们直到最后都坚信这套架构是对的。W公司的故事更糟：管理本地车队租赁业务的公司请来一位”架构师”，为了”控制”开发成本，硬是给这个小业务套上一整套企业级SOA架构——想给销售记录加一个联系人，得先访问ServiceRegistry查ContactService的ID，再发一条有几十个字段（大部分程序员根本拿不到真实数据、只能伪造）的CreateContact消息，拿到新建ID后再发UpdateContact消息给SaleRecordService，测试时还得把消息总线、BPel服务器等一整套基础设施全部跑起来、忍受服务间传递的排队延迟。两个故事的共同教训不是”按服务组织架构本身有问题”，而是在业务需求根本不需要那种规模和复杂度时，就草率、不假思索地把一整套重量级架构模式强加了上去，把大量人力白白耗费在了伺候架构本身，而非解决真正的业务问题。