对技术人员而言，理解 ERP 不能停留在功能清单层面。真正决定系统能否稳定运行、 能否承受业务变化的，是它的架构设计、数据模型与扩展方式。 这篇文章从工程视角梳理几个关键问题。
一、典型的分层架构
主流 ERP 产品无论技术栈如何，逻辑上大多可以划分为四层。分层的目的不是追求形式， 而是隔离变化：业务规则变化时不必改动数据访问层，数据库升级时不必重写界面。
| 层次 | 职责 | 常见技术 |
|---|---|---|
| 表现层 | 页面渲染、表单校验、交互反馈 | B/S 前端框架、桌面客户端 |
| 应用层 | 业务规则、事务编排、流程控制 | 应用服务、工作流引擎 |
| 领域层 | 单据、库存、成本等领域模型 | 领域对象、业务组件 |
| 数据层 | 持久化、查询、报表取数 | 关系型数据库、缓存 |
判断一套 ERP 架构是否健康，一个简单的方法是看：更换数据库或前端框架时，需要改动多少业务代码。
二、数据模型设计的三个原则
原则一：单据不可随意修改
ERP 中的单据一旦审核，就应视为业务事实。需要变更时，通过红冲、调整单或新版本单据来处理， 而不是直接改字段。这样做的核心目的是保证审计线索完整，任何时点的库存与账务都能回溯。
原则二：主数据与业务数据分离
物料、客户、供应商、仓库属于主数据，需要版本管理、启用停用控制与变更审批； 订单、出入库属于业务数据，随流程产生。把两者混在一张表里，后期几乎无法治理。
原则三：余额与流水并存
只存余额，查询快但无法追溯；只存流水，可追溯但汇总慢。实践中通常两者都保留： 流水表记录每一次变动，余额表作为汇总结果，通过事务保证一致，并定期做对账任务。
三、系统集成方式的取舍
ERP 很少孤立存在，通常需要与 MES、WMS、CRM、电商平台、财务共享等系统交换数据。 常见方案有以下几类。
| 方式 | 优点 | 局限 | 适用场景 |
|---|---|---|---|
| 接口调用（HTTP/API） | 边界清晰、可鉴权、易监控 | 需要双方开发配合 | 实时性要求较高的业务协同 |
| 中间表 / 文件交换 | 实现简单、耦合低 | 时效性差、缺少校验 | 批量数据同步、遗留系统对接 |
| 数据库直连 | 开发成本最低 | 强耦合、风险高、难以审计 | 仅在无其他选择时临时使用 |
| 消息队列 | 异步解耦、削峰填谷 | 需处理重复与顺序问题 | 高并发、跨系统事件通知 |
无论选择哪种方式，都应遵循几条底线：接口具备幂等性、失败可重试、全链路有日志、 数据有校验与对账机制。缺少对账的集成分分钟变成“数据黑洞”。
一个幂等处理的示意
// 以业务唯一号作为幂等键，重复请求直接返回已处理结果
function createReceipt(payload) {
const key = payload.sourceSystem + ':' + payload.sourceNo;
const exists = receiptRepo.findBySourceKey(key);
if (exists) {
return { code: 'DUPLICATED', data: exists.id };
}
return transaction(() => {
const receipt = receiptService.create(payload);
receiptRepo.saveSourceKey(key, receipt.id);
return { code: 'OK', data: receipt.id };
});
}四、权限模型
ERP 的权限通常由三个维度组合而成，缺一不可。
- 功能权限：能打开哪些菜单、能执行哪些操作（新增、审核、反审核）。
- 数据权限：能看到哪些组织、仓库、客户范围内的数据。
- 字段权限：某些敏感字段（如成本价、银行账号）对特定角色隐藏或只读。
实践中建议采用“角色 + 数据范围”的模型，避免为每个人单独配置。 同时要保留权限变更日志，满足审计要求。
五、二次开发的边界
二次开发不可避免，但必须控制范围。以下几条经验可以作为判断依据。
- 能用配置解决的，不做开发：字段、单据类型、审批流、打印模板大多可以通过配置完成。
- 不改核心表结构：优先使用扩展表或自定义字段，避免升级时冲突。
- 不绕过业务校验：直接写数据库看似高效，实则绕过库存与账务的一致性检查。
- 不侵入标准流程：通过事件钩子、插件机制扩展，而不是修改标准代码。
- 开发必须可追溯：每项定制有编号、有说明、有责任人，升级前能做影响评估。
一条实用准则：如果一项定制无法用一句话说明它解决的业务问题，那它大概率不该被开发。
六、性能与运维
常见性能瓶颈
- 报表直接扫描大表，缺少合适的索引与汇总表。
- 单据列表一次性加载全量数据，未做分页与条件过滤。
- 库存计算在事务中同步执行，长事务导致锁等待。
- 接口串行调用，单次请求耗时叠加。
运维要点
- 数据库定期备份并做恢复演练，备份文件必须异地保存。
- 关键操作留痕，日志保留周期满足审计与排查需要。
- 上线前进行容量评估，明确数据增长后的归档策略。
- 建立监控指标：接口成功率、慢查询数量、任务队列积压、磁盘空间。
七、小结
架构与开发的讨论最终都要回到一个标准：是否让业务更可靠、让变更更可控。 分层清晰、数据可追溯、集成有对账、权限有边界、定制有约束， 这几条落实到位，系统才能伴随企业走得更久。