把不变的下沉,把变化的抽象
一套用「前沿部署工程师(FDE)」思路重构现有业务系统的完整方法:先抽离原子级的通用业务内核,再在其上做组合、配置与定制扩展,让每一个新客户都比上一个交付得更快。
本系列共十一篇,按一次完整重构的决策旅程排列,由易到难。每一篇都可独立阅读,按顺序读则构成完整闭环。
这个系列要解决什么
大多数业务系统的困境,根源在于「每接一个新客户,都要重做一遍」。
定制本身是收入来源,重复定制才是成本黑洞:第 1 个客户三个月交付,第 5 个客户还是三个月,而维护成本已经翻了五倍。团队规模在涨,交付速度不涨,人效曲线越走越平。
本系列给出一条可执行的解法路径:
- 把系统中最稳定的能力下沉为通用基座;
- 把跨产品复用的共性能力提炼为核心工具层;
- 把真正因客户而异的部分收敛到业务 / 产品层,用组合与配置承接。
让这条路径持续运转的关键角色是前沿部署工程师(Forward Deployed Engineer,FDE):他站在客户现场,对交付结果负责,同时对内核的整洁度负责。这个双重身份,是把「现场经验」变成「内核能力」的传动轴。
全系列的骨架:三层架构
整套方法可以压缩成一张三层结构图。依赖只能从上往下,变化频率只能从下往上递增,这两条规则贯穿十一篇的每一个决策。
| 层 | 职责 | 回答的问题 | 变化频率 | 典型能力 |
|---|---|---|---|---|
| ③ 业务 / 产品层 | 组合、配置、定制扩展 | 怎么用 | 变化最快,按周或按客户 | 客户专属流程、界面装配、规则差异 |
| ② 核心工具层 | 原子级通用业务能力 | 做什么 | 变化中等,按季度演进 | 订单流转、权限、内容、通知、审批流 |
| ① 通用基座 | 让能力跑起来的基础设施 | 怎么跑 | 最稳定,按年迭代 | 执行引擎、调度、日志、安全、资源管理 |
依赖方向:③ 业务层 → ② 核心工具层 → ① 通用基座,箭头单向向下。任何一条从下往上的调用,都是内核开始被客户绑架的信号。
改动代价则相反:越往下越通用、越稳定,一旦改错影响面越大;越往上越贴近客户,改起来越快、越便宜。重构的全部工作,本质上就是不断把「本该稳定的东西」往下挪,把「本该多变的东西」往上挪。
一句话概括全系列:把系统切准,让每一层只承担它该承担的那一类变化。
开读前建议先看术语表。全系列使用了 45 个关键概念——FDE、原子能力、扩展点、绞杀者、边际交付成本……术语表用一句话解释每一个,并标注它出自哪一篇。非技术读者先看这一页,正文会顺畅很多;读到后面忘了某个词,也可以随时回来查。
十一篇导航
第一部分 · 判断与骨架
回答两个前置问题:这件事值不值得做,做完之后系统长什么样。
01 · 认知篇 · 无门槛 每接一个客户,为什么都要重做一遍?
从一场典型的交付困局出发,讲清 FDE 是什么、不是什么,以及它和外包、咨询、传统产品研发的根本区别。全篇无门槛,非技术读者可直接读懂。
02 · 总纲篇 · 基础 三层架构全景:把不变的下沉,把变化的抽象
完整展开「通用基座 / 核心工具层 / 业务层」的职责边界、依赖规则与收益模型。用一个开源引擎加定制扩展的真实类比,说明「内核 + 外挂」为什么能同时兼顾稳定与灵活;并厘清它与中台、微服务、DDD 分层的关系。
03 · 基座篇 · 进阶 通用基座:只负责「让东西能跑起来」的那一层
执行引擎、调度、日志、安全、资源管理——哪些能力该下沉,下沉的判据是什么。给出可自测的下沉决策流程,以及「基座膨胀」的刹车机制。
第二部分 · 设计与抽象
最见功力的部分:怎么把千差万别的业务需求,收敛成一组稳定的原子能力。
04 · 抽象篇 · 进阶 核心工具层:从业务里提炼原子级能力
整套方法里最难的一层。讲清抽象的粒度怎么定、「伪通用」长什么样、为什么「配置先行」优于「抽象先行」,以及抽象过度如何反噬团队。附一份可直接照做的抽象评审会议程。
05 · 产品篇 · 进阶 业务 / 产品层:只负责「怎么用」,不重新造轮子
扩展点设计、定制的三档实现、客户定制如何不污染内核。核心命题:让定制发生在边界上,而不是发生在内核里。
第三部分 · 落地与长效
系统已经在跑,怎么切过去;切完之后,怎么让它不退化。
06 · 落地篇 · 高级 落地路径:绞杀者式迁移与现场闭环
已有系统怎么切。给出分阶段迁移路线、双轨与灰度策略、回滚预案,以及现场经验如何系统性回流为内核能力的完整闭环;并给出迁移中途被迫暂停时的退出路径。
07 · 度量篇 · 高级 度量与反模式:怎么判断重构真的成功了
八类典型反模式(伪通用、配置爆炸、内核被客户绑架、抽象泄漏等)与一套可落地的度量看板。重构失败的常见情形是:架构改完了,指标却没有变化。
08 · 测试篇 · 进阶 三层架构下的测试策略
重构是改结构不改行为,前提是有办法证明行为没变。讲清三层各自的测试强度、契约测试为什么是主力、插件隔离测试的四关,以及迁移期一致率如何自动化。
09 · 隔离篇 · 进阶 多租户与隔离:谁的东西是谁的
多个客户共用一套内核时,配置、数据、运行时、资源四样东西必须隔离,且要靠机制而非约定。含三档隔离选择、租户上下文的四个高发断裂点、舱壁设计。
10 · 组织篇 · 基础 团队分工与考核
架构最终会长成组织的形状。讲清四种角色边界、三种组织形态(只有双轨型成立)、人数配比,以及三类角色该考什么、不宜考什么。
11 · 工具篇 · 实操 投入估算器(可交互)
填入自己的数字,立刻算出重构后单次成本、总投入、回本点(第几个客户)与三年累计节省,并自动生成两条成本曲线的对比图。适合拿去做投入决策时使用。
四条阅读路径
| 你是谁 | 建议读法 | 读完能拿到什么 |
|---|---|---|
| 管理者 / 非技术读者 | 先扫术语表,再读 01、02、07 | 这套方案值不值得投、投进去后看哪些数字、失败会从哪里开始 |
| 架构师 / 技术负责人 | 重点读 02、03、04、05 | 完整的设计方法论;06 与 08 提供落地保障,07 提供验收标准 |
| 一线工程师 | 从 01 建立共识,再读 03、04、05 | 理解代码该落在哪一层;08、09 与日常开发最相关 |
| 想系统读完 | 按 01 → 11 顺序通读 | 十一篇严格递进,后面的内容默认你已经理解了前面的概念 |
阅读约定
- 不出现任何工程代码。全系列用类比、图示和决策规则讲方法,可直接套用到不同的技术栈。
- 涉及具体技术选型的地方,只给判断标准,不给标准答案——答案取决于你的客户结构与团队规模。
- 文中涉及的数字与案例均为示意,用于说明方法本身,不代表行业基准。
怎么用这个系列
单篇可以解决单个问题,整套可以支撑一次决策。实际推进时,比较稳的顺序是:先用 11 的估算器把投入和回本点算出来,确认值得做;再用 02 定骨架、04 和 05 定边界;进入迁移后靠 06 控制风险、08 和 09 兜底质量;最后用 07 的指标验收,用 10 的组织设计防止成果随时间退化。
如果只记住一句话:定制不可避免,重复定制可以避免。十一篇讲的都是同一件事——把不可避免的部分关进边界里,把可以避免的部分变成资产。
用 FDE 重构业务系统 · 十一篇连载 · 建议配合团队内部的架构评审同步阅读。
欢迎浏览更多精彩内容就在知识星球:小小二进制
https://wx.zsxq.com/mweb/views/column/index.html?group_id=48882484885258&column_id=158848415842