定制软件架构与验收清单

先给结论：架构要解释业务变化，验收要覆盖失败路径

定制软件架构的价值，不是把系统画成很多方框，而是说明业务能力如何分组、数据由谁负责、模块如何协作、依赖失败时怎样处理，以及未来变更会影响哪里。验收也不能只走一次正常流程，应覆盖权限越界、重复提交、接口超时、数据冲突、迁移差异、发布失败和恢复等情况。

企业在比较武汉软件开发公司时，可以要求每个重要结论对应一种证据：角色权限矩阵、流程状态图、数据字典、接口清单、测试记录、部署文档或恢复演练。技术栈可以写入方案，但它只是实现选择，不是系统可靠性的充分证明。

一、先确认是否真的需要定制

流程较通用、团队愿意适应标准产品、接口和数据导出满足要求时，应先评估成熟SaaS或可配置产品。只有当关键流程差异、复杂权限、特定设备或平台集成、私有化部署、数据控制和长期演进要求明显时，定制开发才可能带来更高价值。

CRM通常围绕客户、线索、商机和跟进；ERP覆盖采购、销售、库存、生产或财务等更广资源；OA侧重审批、通知和协作；进销存聚焦采购、库存与销售。名称相同并不代表范围相同，立项时应以角色、任务和数据闭环定义首期模块。可先用定制软件需求梳理指南整理现状。

二、用角色、流程、状态和数据建立业务模型

每项需求至少回答：谁在什么条件下，对什么对象执行什么动作，结果怎样变化，失败后怎么办。例如“销售审批”还需说明发起人、审批层级、金额阈值、退回、撤回、超时、代理、离职交接和通知。只有“增加审批功能”无法支持可靠报价和验收。

建议形成四类基础文档：角色权限矩阵说明谁能看和改哪些数据；流程状态图说明正常与异常转换；数据字典说明字段、来源、必填、口径和保存期限；业务规则表说明计算、唯一性、编号和校验。原型用于确认操作路径，但不能替代这些规则。

三、架构评审要回答的8个问题

1. 模块边界按什么业务能力划分，谁拥有关键数据？
2. 客户端、后台任务、接口和管理端怎样协作？
3. 用户身份、组织、角色和数据范围怎样传递？
4. 一次操作失败、重复或超时时怎样保证状态一致？
5. 第三方系统不可用时，是排队、重试、降级还是人工处理？
6. 哪些事件需要审计日志，谁可以查看和导出？
7. 部署、配置、数据库变更和版本回退怎样执行？
8. 容量增长、业务扩展和维护人员变化时，系统怎样继续运行？

不必追求过度复杂的分布式架构。首期用户量和流程有限时，边界清晰、易测试、易部署的结构通常更合适。只有在并发、隔离、团队协作或独立扩展确有需要时，再引入额外复杂度。所谓“微服务、云原生、AI驱动”必须对应具体问题、监控和运维能力。

四、权限、安全与日志清单

权限至少分为功能权限、数据范围和敏感操作控制。能打开“客户管理”页面，不代表能查看所有部门客户；能编辑订单，也不一定能改金额、作废或导出。应测试未登录、普通用户、跨部门、离职账号、链接直达和接口调用等越权场景。

安全基线可参考OWASP应用安全验证标准建立项目适用的检查项，包括认证、会话、访问控制、输入处理、数据保护、通信和配置等。日志应记录关键业务和管理操作，但不应无边界保存密码、令牌或敏感个人信息。安全范围要结合系统风险分级，任何检查都不能承诺永远没有漏洞。

五、历史数据迁移不能只看“导入成功”

从Excel、旧CRM或ERP迁移时，先确定数据所有者和使用口径，再检查重复、缺失、编码、日期、关联、无效账号和历史状态。建议选择代表性样本做试迁移，记录源数量、清洗规则、成功失败数、字段差异和关键金额或库存对账。

正式迁移应写明停机窗口、增量数据处理、备份、执行顺序、验证人和回退条件。无法从旧系统合法导出的字段，或企业内部无法确认的历史口径，不能由开发团队自行推断。迁移验收的目标是数据在新系统中准确、可追溯且能支持后续流程，不只是数据库里出现了记录。

六、系统集成验收要覆盖接口失败

连接财务软件、企业微信、支付、短信、物流或设备前，应核验接口所有者、授权方式、字段、频率限制、测试环境、费用和服务承诺。接口清单要说明同步方向、触发条件、幂等标识、超时、重试、告警、人工补偿和对账。

验收不仅要看一条成功数据，还要模拟凭证失效、网络超时、重复回调、字段缺失和第三方返回异常。若外部平台没有开放所需能力，定制系统不能绕过其规则实现；若第三方后续调整接口，也可能产生独立改造成本。

七、从功能测试扩展到业务验收

八、私有化部署与上线切换

私有化部署适合明确需要本地或专属环境，并且组织能够承担服务器、数据库、网络、安全更新、监控、备份和人员权限的项目。它不自动比云服务安全，也不意味着没有持续费用。方案应列出环境责任矩阵，说明开发方、客户IT和第三方分别维护什么。

上线前需要版本、配置、数据库脚本、备份、监控、联系人和回退条件；上线后要验证核心流程、任务队列、接口、日志、告警和数据。若采用分批切换或试运行，还要说明新旧系统数据如何同步、哪一个是最终口径以及何时停止旧系统。

九、交付不是一个安装包，而是一套可继续维护的资产

常见移交项包括需求和范围、原型、架构说明、数据字典、接口文档、测试记录、部署与恢复说明、代码仓库、构建方式、配置清单、第三方组件许可、服务器和平台账号、管理员操作说明及已知限制。每项都要注明是否包含、格式、持有人和更新时间。

源码交付不等于客户立即具备维护能力，还需要依赖、环境、部署权限和知识转移。第三方开源或商业组件也有各自许可，不能默认全部权利都随项目转让。缺陷处理、环境更新和新增需求应分别定义，避免上线后所有变化都被混称为“售后”。

十、需要警惕的方案信号

• 不看现有流程和数据，就按“CRM一套”或“ERP一套”固定报价。
• 只列功能菜单，不说明角色、状态、异常、接口和数据口径。
• 用最新技术、AI或微服务作为卖点，却没有测试、监控和回退说明。
• 声称私有化绝对安全，或承诺任何第三方系统都能无条件打通。
• 迁移前不做样本和差异确认，上线前没有真实角色参与验收。
• 域名、服务器、代码、数据库和平台账号归属始终不写入合同。

这些信号不自动证明供应商不合格，但意味着项目风险尚未被解释。应要求对方补充条件、交付物和责任人，再决定是否继续。

来源与适用边界

本文在通用软件工程与项目验收实践基础上，参考OWASP应用安全验证标准（ASVS）用于说明可按风险选择安全验证要求。该标准是安全检查参考，不替代针对具体行业、数据类别、部署环境和当地法规的专业评估。

本文不指定某种编程语言、数据库、云平台或架构风格，也不承诺使用清单即可消除所有缺陷。实际范围应根据业务风险、用户规模、系统依赖和合同确定。梓彤超越的实施边界见武汉定制软件开发服务，更多CRM、ERP、OA、进销存和系统集成问题见定制软件业务问答。