AHAX 公开知识库阶段 · 文章
03 业务系统架构：CRM、ERP、后台、小程序与 App 的边界
先把角色、对象、终端、同步与运维边界说清，再决定模块化单体、微服务还是混合方案。
最后更新 · 预计阅读 · 12 分钟
很多项目一开始不是缺开发能力，而是缺边界：谁在用，改什么数据，在哪个终端完成，哪个系统负责唯一事实来源，哪些变化必须实时同步，哪些延迟可以接受。
事实：CRM、ERP、MES、OA、管理后台、业务系统、客户门户、小程序和 App 都只是边界标签，不是厂商答案。外部证据：公开标准和技术文档支持安全基线、质量测量、架构取舍、日志管理、离线能力、Web 安全验证和 HTTP 语义。AHAX 判断：系统边界应由角色、动作、对象、事件和终端共同决定。示意情境：工贸企业把审批、录入、查询、拍照和扫码拆到不同终端，才避免了“所有人都在一个页面里做所有事”。这只是示意，不是客户案例。
管理者先看结论
Section titled “管理者先看结论”管理者先看结论：先定系统边界，再定数据边界，再定同步边界，最后才定技术边界。
AHAX 判断：对大多数中小团队，默认优先模块化单体，先把业务边界、主数据、权限和流程跑顺；只有在团队、部署和运维边界都需要独立时，才考虑拆微服务。
系统边界先分清
Section titled “系统边界先分清”| 系统 / 终端 | 主要职责 | 典型使用者 | 不该替代什么 |
|---|---|---|---|
| CRM | 客户、商机、跟进、线索和销售过程 | 销售、客服、销售管理 | 不替代 ERP 的库存、财务和生产口径 |
| ERP | 采购、库存、财务、计划、结算和经营核算 | 计划、财务、采购、管理层 | 不替代客户前台和复杂外部协同 |
| MES | 生产执行、工序、报工、设备、质检和追溯 | 车间、班组、工艺、生产管理 | 不替代面向客户的门户和销售流程 |
| OA | 审批、通知、制度、台账和协同流转 | 全员、行政、管理者 | 不替代业务主流程和主数据系统 |
| 管理后台 | 配置、内容、字典、权限、规则和运营管理 | 运营、管理员、数据维护人 | 不替代面向客户的完整业务闭环 |
| 业务系统 | 跨角色流程、状态流转、规则、对账和闭环 | 业务部门、管理者、一线人员 | 不替代通用办公工具的轻量协同 |
| 客户门户 | 客户查询、提交、下载、跟踪和授权动作 | 客户、渠道、门店、合作方 | 不替代内部管理和后台配置 |
| 小程序 | 轻量移动入口、查看、提交、扫码、拍照 | 外勤、客户、渠道、门店 | 不替代复杂录入、批量处理和深度管理 |
| App | 可靠离线写入、后台任务、稳定推送、深度设备集成 | 高频外勤和现场人员 | 不替代低频浏览、扫码或拍照 |
角色 - 动作 - 终端映射
Section titled “角色 - 动作 - 终端映射”| 角色 | 典型动作 | 更合适的终端 | 不合适的终端 |
|---|---|---|---|
| 管理者 | 看报表、审异常、定规则、拍板 | 电脑端业务系统 / 管理后台 | 手机里做复杂批量录入 |
| 销售 / 客服 | 录入线索、跟进、查询、派单 | CRM + 电脑端 | 让客户门户承担内部流程 |
| 计划 / 仓储 | 看库存、排产、收发货、对账 | ERP / MES + 电脑端 | 用 App 做大批量维护 |
| 财务 / 审批 | 审核、结算、复核、追踪 | OA / ERP + 电脑端 | 让移动端承载复杂凭证 |
| 外勤 / 现场 | 拍照、扫码、定位、报工、签收 | 小程序 / 移动 Web | 把拍照、扫码直接等同 App |
| 客户 / 渠道 | 查状态、提资料、下单、下载 | 客户门户 / 小程序 | 让其进入内部后台 |
- 先判断谁是业务 owner、数据 owner 和终端 owner。
- 再判断哪些对象必须有唯一事实来源，哪些可以最终一致。
- 再判断哪些动作必须实时，哪些动作可以异步。
适用与不适用
Section titled “适用与不适用”这篇适合已经明确“要管什么业务”的项目，不适合只想“先做一个看起来像系统”的情况。
| 场景 | 适合 | 不适合 | 说明 |
|---|---|---|---|
| 内部管理后台 | 配置、台账、审批、内容、字典和权限 | 想替代完整业务闭环 | 后台偏管理，不偏前台业务 |
| 业务系统 | 订单、工单、任务、状态、对账和协同 | 只做展示不做流转 | 业务系统必须能闭环 |
| 客户门户 | 外部查询、提交、下载、跟踪、授权 | 承担内部审批和复杂配置 | 门户面向外部用户，不面向运维人员 |
| 多端协同 | 各终端分工明确 | 同一页面复制到所有端 | 按动作分配终端 |
| 离线 / 设备能力 | 可靠离线写入、后台任务、设备集成 | 仅浏览、扫码、拍照 | 能力不是默认项 |
| 数据归属清楚 | 每个对象都有唯一责任系统 | 多套系统都说自己是主口径 | 先定主数据责任，再谈同步 |
| 终端 | 适合什么 | 主要限制 | AHAX 判断 |
|---|---|---|---|
| 电脑 Web | 复杂录入、批量处理、报表、配置 | 移动性弱 | 复杂业务优先放这里 |
| PWA | 轻量提交、弱网与部分离线 | 需实现 Service Worker 等能力 | 满足工程条件才承诺离线 |
| 移动 Web / H5 | 浏览、短表单、扫码、拍照 | 默认在线，后台能力有限 | 短流程优先，不宣称 PWA 级离线 |
| 小程序 | 扫码、拍照和短流程 | 平台与能力边界受限 | 轻量任务优先，不作为架构结论 |
| App | 可靠离线、后台任务、稳定推送、设备集成 | 研发、分发、维护成本高 | 有持续使用或分发价值才考虑一期 |
AHAX 判断：扫码、拍照和短流程优先小程序或移动 Web。仅在可靠离线写入、后台持续任务、稳定推送、深度设备集成或应用分发有明确价值时，才考虑一期 App；定位 App 看使用持续性与后台能力。
给管理者看边界是否匹配。
| 方案 | 团队边界 | 部署边界 | 运维边界 | 优点 | 代价 |
|---|---|---|---|---|---|
| 模块化单体 | 一个主团队、一个主节奏 | 一套发布流水线 | 一套监控、日志和恢复 | 边界清楚、调试简单、交付快 | 共享进程，隔离度较低 |
| 微服务 | 多团队分别负责独立能力 | 服务可独立部署 | 需要更强的观测、告警和链路追踪 | 独立扩缩容、独立发布 | 分布式复杂度高，不适合为了“先进”而拆 |
| 混合方案 | 核心流程集中，少数能力独立 | 关键能力单独部署 | 关键边界单独运维 | 兼顾稳定和局部独立 | 接口和责任边界更复杂 |
AHAX 判断：没有独立团队、独立发布节奏和成熟运维能力时，不要把微服务当默认答案。模块化单体更适合先把业务跑通。
API、同步、事件、批处理怎么选
Section titled “API、同步、事件、批处理怎么选”| 方式 | 适合场景 | 主要优点 | 主要边界 |
|---|---|---|---|
| API | 查询、提交、校验、同步动作 | 反馈快、语义直观 | 依赖在线可用性，失败处理要明确 |
| 事件 | 状态变化广播、多个系统订阅 | 解耦、可扩展、便于异步处理 | 要处理重复消费、乱序和回放 |
| 批处理 | 夜间结算、历史回补、导入导出、对账 | 吞吐高、适合批量修正 | 时效慢，不能替代实时链路 |
| 人工对账 / 补录 | 低频例外、历史清理、应急恢复 | 简单可控 | 不能把人工当成长期设计 |
AHAX 判断：实时链路优先 API，状态广播优先事件，批量修正优先批处理。
一致性、重试、幂等与对账
Section titled “一致性、重试、幂等与对账”公开文档支持的是边界，不会替你决定哪一条业务必须强一致。这里的判断要落回业务风险：金额、库存、权限和状态能不能错，错了以后能不能补。
AHAX 判断：对高风险动作，先定义唯一来源，再定义写入顺序和失败回滚。AHAX 判断：对异步链路，必须有幂等键、重试上限、超时、告警和去重。AHAX 判断：只要存在最终一致，就必须有对账表、补偿动作和人工兜底入口。AHAX 判断：不要让“接口返回成功”直接等于“业务已经成功”，中间要留出可复核状态。
如果某个动作一旦重复、丢失或晚到就会直接造成损失，才考虑更严格的一致性和更短的链路；如果只是列表同步、报表汇总或非关键通知，最终一致通常更现实。
主数据责任矩阵
Section titled “主数据责任矩阵”| 对象 | 唯一责任系统 | 维护人 | 同步用途 | 备注 |
|---|---|---|---|---|
| 客户 | CRM 或客户主档系统 | 销售运营 / 客户运营 | 门户、合同、结算、服务 | 客户名称和编码必须唯一 |
| 组织 / 部门 | 组织主数据系统 | 人事 / 行政 / 管理者 | 权限、审批、报表 | 组织变更要可追溯 |
| 产品 / 物料 | ERP / 物料主档 | 供应链 / 产品管理 | 订单、库存、采购、生产 | 编码、规格、单位统一 |
| 价格 / 折扣 | 价格主档或 ERP | 销售管理 / 财务 | 报价、订单、结算 | 版本和生效时间要清楚 |
| 订单 / 合同 | 业务系统或合同主档 | 业务 owner | 财务、交付、客服 | 主状态要有唯一来源 |
| 库存 / 在途 | ERP / WMS / 业务系统之一 | 仓储 / 供应链 | 订单、出库、采购、计划 | 不能多头维护 |
| 工单 / 任务 | 业务系统或 MES | 业务部门 / 班组 | 排班、回访、质检 | 状态流转要统一 |
| 权限角色 | 身份与权限系统 | IT / 安全 / 管理者 | 所有终端 | 权限不是随页面临时配置 |
AHAX 判断：主数据不是“同步次数越多越好”，而是“唯一责任谁来担”。
实施先做系统上下文，再做主数据，再做接口和权限。不要先追着页面做，页面越快，返工越快。
第一阶段要产出的东西
Section titled “第一阶段要产出的东西”| 产出 | 必须包含什么 | 谁来确认 | 为什么先做 |
|---|---|---|---|
| 系统上下文图 | 角色、终端、系统、主数据、事件、外部系统 | 业务 owner + 技术负责人 | 先看全局边界 |
| 主数据表 | 对象、唯一责任系统、编码、维护人、同步方向 | 数据 owner | 先定谁说了算 |
| 接口清单 | 来源、去向、频率、方式、失败处理、回滚 | 技术 + 业务 | 先看怎么连，不是先看怎么写 |
| 权限矩阵 | 角色、对象、动作、可见范围、审批链 | 业务 owner + 安全 | 先防越权和误操作 |
| 异常 / 补偿清单 | 失败、重复、超时、离线冲突、人工补录 | 业务 + 技术 | 先想清楚出事怎么办 |
系统上下文图应该怎么画
Section titled “系统上下文图应该怎么画”图里至少要出现人、终端、系统、主数据和事件。每条线都要写清楚“谁发起、谁负责、谁确认、失败后怎么办”。
你可以按这个顺序画：
- 先画角色和终端，不先画按钮。
- 再画系统和对象，不先画库表。
- 最后画事件和同步，不先画代码。
异常和补偿要写在一期边界里
Section titled “异常和补偿要写在一期边界里”常见异常至少要有以下几类：
- 接口超时或失败后是否重试，重试几次，谁接到告警。
- 同一笔提交重复到达时是否去重，去重键是什么。
- 离线提交和在线编辑发生冲突时，按什么规则合并。
- 批量导入失败后是整批回滚，还是部分成功、部分补录。
- 外部系统晚到、漏到、错到时，如何人工对账和补偿。
AHAX 判断：异常处理是一期设计的一部分。没有补偿清单的系统，最后往往会把问题留给人和表格。
最容易出问题的不是代码，而是边界被反复改写。下面这张表要和第一版范围一起看。
| 风险 | 影响 | 负责人 | 早期信号 | 应对 | 退出 / 降级 |
|---|---|---|---|---|---|
| 主数据多头维护 | 同一对象多套口径，报表和流程都失真 | 数据 owner | 客户名、产品名、库存数反复打架 | 先定唯一责任系统，再定同步方向 | 口径两轮仍不一致，就先停开发 |
| 权限边界模糊 | 越权、误操作、内部泄露 | 安全 / 管理者 | 角色越来越多，临时例外越来越多 | 建权限矩阵和最小权限原则 | 无法收敛角色时，先降级为只读 |
| 同步链路不稳 | 重复、漏单、延迟，自动化反而制造新错 | 技术负责人 | 失败重试很多，人工补录频繁 | 加幂等、重试、对账和告警 | 无法稳定补偿就收缩为手工流程 |
| 离线冲突处理缺失 | 现场录入与总部更新互相覆盖 | 产品 / 技术 | 手机先提交、电脑后改动 | 明确冲突优先级和回写规则 | 不能定义合并规则时，先取消离线写 |
| 多端职责混乱 | 每个端都长得像“全能后台” | 产品负责人 | 手机端字段越来越多 | 让不同端承担不同任务 | 无法分工时，先回到单一电脑端 |
| 接管失败 | 企业后期无法自主管理、迁移、恢复 | 企业管理者 | 账号散落、文档缺失、恢复没演练 | 做接管清单和演练 | 无法接管前，不进入正式上线 |
AHAX 判断：退出和降级不是失败，而是止损。能从复杂方案退回到更小闭环，比硬撑一个不稳定系统更省钱。
验收要验证的是“边界是否清楚、流程是否可复核、失败是否可恢复”，不是看演示效果。下面这些指标必须能用证据证明。
| 验收项 | 证据 | 通过标准 |
|---|---|---|
| 角色权限 | 权限矩阵、登录截图、操作日志 | 每个角色只能看见并执行授权动作 |
| 数据唯一来源 | 主数据表、同步记录、对账结果 | 每个关键对象只有一个责任系统 |
| 接口失败 | 失败样本、重试记录、告警记录 | 失败能被发现、能重试、能追踪 |
| 同步 / 对账 | 对账单、差异单、补偿单 | 差异有处理闭环，不靠人工记忆 |
| 离线冲突 | 冲突样本、合并规则、结果日志 | 冲突可识别、可回放、可解释 |
| 日志 | 操作日志、审计日志、导出日志 | 关键操作可追踪到人和时间 |
| 安全验证 | HTTPS、默认账号关闭、导出控制、敏感字段保护 | 基线项可复测，问题有修复记录 |
| 接管 | 域名、账号、配置、备份、恢复、文档移交 | 企业能独立接管，不依赖个人账号 |
AHAX 判断：没有通过验收的权限、日志、恢复和接管能力，不能因为“已经能跑”就算通过。系统能运行，不等于企业能接管。
这一章最重要的练习，不是继续找架构名词，而是把你的业务画成一张能讨论、能修改、能验收的图。
| 作业 | 要画什么 | 最终产出 |
|---|---|---|
| 系统上下文图 | 人、终端、系统、主数据、事件、外部系统 | 一张能拿去评审的边界图 |
| 主数据表 | 对象、唯一责任系统、编码、维护人、同步方向 | 一张主数据责任表 |
| 接口清单 | 来源、去向、方式、频率、失败处理 | 一张接口清单 |
| 权限矩阵 | 角色、对象、动作、范围 | 一张权限矩阵 |
| 异常 / 补偿清单 | 失败、重复、冲突、补录、回滚 | 一张异常补偿表 |
- 选一个真实流程，不要选最简单的流程。
- 画出角色和终端，再画出系统和对象。
- 给每条线标注同步方式、责任人和失败处理。
- 把图拿给业务 owner 讲一遍，看看哪些地方说不清。
- 让管理者只盯边界、责任和验收，不先讨论页面好不好看。
AHAX 判断：如果一张图画了很多系统，却说不清谁负责哪个对象、哪个动作和哪个终端，那说明问题还没收敛。
外部技术文档与标准
Section titled “外部技术文档与标准”| 类型 | 来源 | 发布机构 | 链接 | 使用边界 |
|---|---|---|---|---|
| 标准信息页 | 《信息安全技术 网络安全等级保护基本要求》 | 国家标准信息公共服务平台 / 国家市场监督管理总局 / 国家标准化管理委员会 | https://openstd.samr.gov.cn/bzgk/std/newGbInfo?hcno=BAFB47E8874764186BDB7865E8344DAF | 只支持安全基线的元数据写法，不替代项目权限模型 |
| 标准信息页 | 《系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第22部分：使用质量测量》 | 国家标准信息公共服务平台 / 国家市场监督管理总局 / 国家标准化管理委员会 | https://openstd.samr.gov.cn/bzgk/std/newGbInfo?hcno=7E7DB6C9A0A135A1C8292C7CC3A88B9C | 只支持使用质量可测，不替代项目验收结论 |
| 架构指南 | Microservices architecture style | Microsoft Learn | https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices | 只支持微服务的技术语境，不支持“所有项目都该拆服务” |
| 数据指南 | Data considerations for microservices | Microsoft Learn | https://learn.microsoft.com/en-us/azure/architecture/microservices/design/data-considerations | 只支持数据主权和一致性边界，不替代主数据责任判断 |
| 架构指南 | Common web application architectures | Microsoft Learn | https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures | 只支持单体与分布式的背景说明，不替代选型结论 |
| 日志管理 | Guide to Computer Security Log Management | NIST CSRC | https://csrc.nist.gov/pubs/sp/800/92/final | 只支持日志管理重要性，不直接给项目日志字段清单 |
| 安全验证 | OWASP Application Security Verification Standard (ASVS) | OWASP Foundation | https://owasp.org/www-project-application-security-verification-standard/ | 只支持 Web 安全验证思路，不替代企业验收 |
| 离线能力 | Build an offline-first app | Android Developers | https://developer.android.com/topic/architecture/data-layer/offline-first | 只支持 App 离线能力边界，不表示所有移动端都要离线 |
| Web 能力 | Application Lifecycle - Roadmap of Web Applications on Mobile | W3C | https://www.w3.org/2019/04/web-roadmaps/mobile/lifecycle.html | 只支持 Service Workers 与弱网能力，不替代终端选型 |
| 协议语义 | Building Protocols with HTTP (RFC 9205) | IETF / RFC Editor | https://www.rfc-editor.org/info/rfc9205 | 只支持 HTTP 语义与协议设计，不生成企业同步策略 |
AHAX 判断
Section titled “AHAX 判断”CRM、ERP、MES、OA先当边界标签，不是采购结论。管理后台偏配置和规则，业务系统偏流程和闭环；主数据先定唯一责任系统。模块化单体是默认优先项。PWA、小程序、App只是终端选择；一致性、重试、幂等、对账和补偿必须写进一期设计。- 不提供固定报价、周期或性能保证。
最后核验：2026-07-15