在现代软件开发过程中，我们常常会遇到对接“古老系统”的场景。这些系统可能由上一个时代的开发团队构建，年代久远，结构混乱，命名不规范，缺乏文档，开发者已经离职，甚至已经不再维护。但由于其仍然承担着关键业务功能，我们必须面对并与之集成。
本文将从实际工程的角度出发，探讨在无法动老系统的前提下，我们应采取的策略、架构方案与工程规范，以实现有效的对接与演进。
一、古老系统的典型特征
命名混乱：字段名无统一规范，如“MXBH”、“DJBH”、“S1”、“UDF1”等，语义模糊。
无文档：系统设计文档缺失，逻辑全靠经验猜测。
无测试：没有测试用例，不能直接改动，无法验证影响。
接口混乱：没有REST规范，可能是WebService、TCP Socket，甚至是通过数据库共享表实现“通信”。
耦合严重：业务逻辑嵌入UI层，模块间高耦合。
二、对接原则：不动老系统的前提下，隔离风险
“不改变老系统，隔离其混乱，保护现代系统。”
1. 建立“防腐层”（Anti-Corruption Layer，ACL）
在领域驱动设计（DDD）中提出ACL概念，即通过中间层将老系统与新系统隔离。
做法：
不直接使用老系统的字段/接口。
通过 Adapter/Translator 模式，将老系统的数据映射为领域模型。
所有老系统交互通过 ACL 层完成，便于未来替换或脱离依赖。
2. 编写系统字段与领域模型的映射规范
例如：
| 老系统字段 | 映射含义 | 新字段名（领域模型） |
|---|---|---|
DJBH |
单据编号 | billNo |
MXBH |
明细ID | detailId |
S1 |
自定义字段1 | customField1 |
使用静态映射表、注解或者配置化（如YAML）映射字段，避免在业务逻辑中硬编码。
3. 构建专门的对接模块/微服务
如有条件，建议将老系统对接逻辑放入单独微服务中，职责单一，只做协议转换和数据规范化。
4. 使用数据同步或镜像机制
对于通过数据库共享数据的情况：
可以使用定时任务、ETL工具或消息中间件（如Kafka）同步数据至中间表。
利用CDC技术（Change Data Capture）实现增量同步。
5. 借助低代码平台或中间件
对于极度混乱系统，可考虑使用低代码平台快速构建接口代理或管理工具，降低维护成本。
三、业务语义不清晰怎么办？
1. 数据驱动反推业务逻辑
样本分析：导出典型单据，观察字段组合与变化趋势。
流程对照：观察老系统UI操作流程，与数据库字段变化结合分析。
日志分析：如老系统日志存在，可以从中提取接口调用和业务路径。
2. 与业务人员协同建模
搭建新业务模型草图，邀请资深业务人员验证。
将“模糊逻辑”显性化，通过表格/流程图重新还原业务。
四、如何保持团队大局观？
1. 明确“对接是过渡，不是归宿”
在团队内达成共识：对接老系统的最终目的是脱离依赖，封装混乱，不让混乱蔓延。
2. 制定统一接入规范
所有老系统对接必须经过 ACL 层。
禁止业务层直接使用老字段名。
所有老字段需有中文注释与语义说明文档。
3. 分阶段替换与拆解
可通过以下策略逐步替换老系统：
数据镜像 + 只读接口。
某些功能模块迁移（如单据打印、库存查询）。
新模块与老模块并行运行，逐步引导用户迁移。
五、总结：构建“现代系统的保护伞”
面对老系统，“动不了”是常态，“抽象隔离”是解法。我们不应试图修复老系统的混乱，而应通过工程与架构手段将其控制在边界之外。
建议采取以下组合策略：
| 目标 | 措施 |
|---|---|
| 命名不规范 | 建立字段映射表，统一术语 |
| 接口混乱 | 封装对接层，设计REST规范 |
| 无文档/无测试 | 建立回归测试用例，反向建模 |
| 系统耦合 | 拆出对接微服务，清晰边界责任 |
| 缺乏大局观 | 统一接入规范，设立架构治理制度 |
在对接老系统时，架构师不仅是技术的桥梁，更是秩序的缔造者。唯有以耐心、规范、与未来导向的视角，才能将“老系统”变成“可控遗产”，最终实现业务现代化演进。