【演进式架构】短期项目如何吸收演进式架构

短期项目不是不需要架构，而是不需要重型架构。它真正需要的，是用最小成本守住最关键的变化风险。

《演进式架构》给出的核心定义是：演进式软件架构支持“跨多个维度的引导式增量变更”。这句话可以拆成三个层次：先知道变化要往哪里走，再用小步方式推进，最后从代码、数据、接口、部署等多个维度确认系统没有被破坏。

因此，短期项目实践演进式架构，不是搭建完整治理体系，而是建立一个轻量闭环：

知道保护什么
小步改变
用反馈确认没坏

一、第一层：短期项目也需要架构，但需要的是“护栏”

很多人一听到架构，就想到分层、框架、微服务、治理平台、自动化流水线。这些东西不一定适合短期项目。

短期项目的核心矛盾是：时间短、变化快、交付压力大。如果一开始投入过多架构设计，容易拖慢交付；但如果完全没有架构意识，项目后期又会变成到处打补丁，越改越怕。

所以短期项目最合适的架构方式，不是“完整设计”，而是“关键护栏”。

所谓护栏，就是提前识别项目中最不能坏的地方，并用很小的规则把它保护起来。

比如：

订单状态不能乱跳
支付接口不能散落调用
数据库结构不能手工乱改
关键 API 返回格式不能随便变
核心计算逻辑不能写在页面里

这些规则不复杂，但能防止短期项目在最后阶段突然失控。

二、第二层：演进式架构的三个关键词

1. 引导式：先知道什么不能坏

“引导式”说明架构变化不是随便变，而是有方向。这个方向来自项目最重要的架构特征。

在长期系统里，架构特征可能是高可用、可扩展、安全性、可维护性、可部署性。短期项目不需要列那么多，但至少要回答一个问题：

这个项目里，哪一块坏了最麻烦？

如果是订单系统，可能是状态流转。
如果是报表系统，可能是计算规则。
如果是集成项目，可能是外部接口。
如果是后台管理系统，可能是权限控制。
如果是数据项目，可能是导入、清洗和迁移。

找到这个点，才知道架构要保护什么。

2. 增量式：每次只保护一个小风险

“增量式”说明变化要小步推进。短期项目尤其不能一上来做大而全的架构。

比如你要对接支付平台，不需要一开始封装完整支付 SDK。第一步只需要封装当前用到的 createPayment()。

你要做订单状态管理，也不需要一开始引入复杂状态机框架。第一步只需要把最关键的状态变化集中到一个函数里。

增量式的价值在于：改动越小，越容易验证；越容易验证，越敢继续改。

3. 多个维度：不要只盯代码

书里强调“多个维度”，这是很多短期项目最容易忽略的地方。

架构风险不只来自代码结构，还来自：

数据结构
外部接口
API 契约
部署环境
权限安全
团队协作

短期项目后期最常见的返工，往往不是“类设计不好”，而是数据库手工改乱了、接口字段改崩了、环境变量漏配了、第三方 API 变化没人知道。

所以，短期项目的架构意识要从“代码怎么分层”，扩展到“哪些变化会让项目交付失败”。

三、第三层：落地方法，用四句话推进

短期项目可以用一个很简单的模板来实践：

风险点：哪里最怕坏？
架构底线：这件事必须遵守什么规则？
小步动作：先做哪一个最小改动？
反馈方式：怎么确认它没有被破坏？

这个模板就是演进式架构的轻量版。

它把书里的“适应度函数”压缩成短期项目能用的形式。你不需要一开始搭复杂工具，只要有一个测试、一个检查、一个脚本，甚至一个明确的 review checklist，都可以先开始。

四、具体实践例子

例子一：外部接口对接

风险点：第三方支付、短信、地图或大模型 API 变化，会污染业务逻辑。

架构底线：

业务代码不能直接调用第三方 API，必须经过 client 层。

小步动作：

先抽出 PaymentClient，只封装 createPayment。

反馈方式：

业务测试里 mock PaymentClient。
代码 review 时检查业务层不能直接写 fetch 或 axios 调第三方地址。

这保护的是“外部变化不要扩散到核心业务”。

例子二：订单状态流转

风险点：订单、审批、工单、任务状态被随手修改，后期出现脏状态。

架构底线：

状态只能通过统一的状态流转函数修改。

小步动作：

先覆盖最关键的状态路径。

例如：

待支付 -> 已支付：允许
已支付 -> 已完成：允许
待支付 -> 已完成：禁止
已完成 -> 已取消：禁止

反馈方式：

写状态流转测试。

这保护的是“核心业务规则不能被无意破坏”。

例子三：数据库变更

风险点：开发、测试、生产环境表结构不一致。

架构底线：

数据库结构变化必须通过 migration。

小步动作：

每次只做一个小迁移，比如新增字段或加索引。

反馈方式：

本地或 CI 从空库执行迁移，确认能成功。

这保护的是“数据结构变化可追踪、可复现”。

例子四：API 返回格式

风险点：后端改字段，前端或调用方突然崩溃。

架构底线：

关键接口返回结构不能无意变化。

小步动作：

先保护最核心的 1-3 个接口。

例如：

GET /api/order/:id 必须返回 id、status、amount、createdAt。

反馈方式：

写一个接口测试或契约测试。

这保护的是“系统之间的协作契约”。

例子五：发布部署

风险点：本地能跑，线上失败。

架构底线：

发布前必须通过统一检查。

小步动作：

提供一个 check 命令。

例如：

lint
test
build

反馈方式：

发布前或 CI 中必须跑通。

这保护的是“交付质量底线”。

五、结论：短期项目要的是轻量演进能力

演进式架构不是只有大系统才能用。它的思想适用于所有项目，因为所有项目都会变化。

但短期项目不能照搬完整体系。它应该裁剪成三个动作：

找到最怕坏的地方
加一条最小护栏
用一个反馈机制确认没坏

这就是短期项目最合适的演进式架构实践。

它不追求架构完美，也不追求治理完整。它追求的是：在有限时间里，让项目最关键的部分不失控，让变化可以继续发生，而不是每改一步都提心吊胆。