工装模具管理系统典型技术架构：分层设计与模块划分-育师

导语

前两批把功能层拆完了，从本篇起进入架构层。工装模具管理系统的架构并不神秘，但它有一个普通业务系统没有的约束：它必须同时服务两个世界——办公室里用浏览器看报表的模具主管，和车间里拿着扫码枪、刷工卡、隔着机油摸屏幕的操作工。这个约束决定了它的分层结构、客户端形态和通讯设计。本篇拆解这类系统的典型分层架构（三层/五层）、各层职责边界、中间件层在设备采集场景里的关键作用，以及模块划分的参考结构。适合做选型评估的 IT 负责人、准备自研的技术团队，以及想看懂厂商架构图的实施顾问。

一、总体分层：从三层到五层

市面上的工装模具管理系统，公开资料里能看到的架构形态基本是两种：经典三层和扩展五层。

三层架构是基线：表现层（Web 端 + 车间端 + 移动端）、业务逻辑层（领域服务）、数据访问层（数据库 + 文件存储）。对于纯台账型系统（登记、查询、盘点），三层完全够用。但只要涉及模具寿命管控和设备采集，三层就开始吃力——原因在第七篇讲过：冲次数据从注塑机到系统要经过 PLC、网关、协议解析多道环节，这些"非业务"的脏活累活不该塞进业务逻辑层。

五层架构在三层之上拆出两层：

接入层：Web 门户、小程序/H5、车间 CS 端、PDA 扫码端、开放 API。统一网关做认证、限流、路由；
应用服务层：档案、库存、工单、预警等业务模块的服务化拆分；
中间件/采集层：设备通讯网关、协议解析（Modbus/OPC UA/厂商私有协议）、消息队列、规则引擎（预警阈值计算）、报表引擎。这一层是模具系统与普通资产管理系统的分水岭；
数据层：关系库（业务数据）+ 文件/对象存储（图纸、点检照片）+ 时序数据（冲次流水的可选形态）；
基础设施层：服务器/云资源、RFID 读写器、智能模具柜、工控机等硬件。

中间件层的职责要划清楚，三条边界不能破：它不做业务决策——阈值判断结果由规则引擎算出后交给应用层落单据，中间件不直接改模具状态；它不做界面——采集配置属于中间件自己的管理界面，不混进业务前端；它必须有独立的心跳监控——第七篇讲过的断传告警，监控对象就是这一层。

二、客户端形态：CS、BS 与双端并存

调研到的公开方案里，"CS + BS 双端"是高频组合，这不是历史包袱，而是场景必然：

**BS 端（浏览器）**管"看和批"：台账查询、报表看板、审批流、系统配置。优点是零安装、升级即生效，管理层和办公室场景首选。

**CS 端（车间客户端）**管"快速操作"：领用归还刷卡、上下机扫码、点检拍照。车间场景对 BS 是真实的坑——车间网络经常不稳，浏览器扫码枪驱动兼容性参差，而且公开方案明确提到 CS 端"刷卡登录以便快速准确识别操作人"，硬件直连（读写器、双屏、人脸仪）在 CS 下实现成本低得多。

**移动端（小程序/PDA）**管"流动场景"：外协收发、异地盘点、领导随时查进度。公开方案普遍把"客户查询自家模具进度"放在小程序，就是吃定了移动端不需要培训的特性。

架构上的对应关系：三端共用同一套应用服务层 API，差异只挂在接入层。评估厂商方案时可以问一个问题来验架构质量："车间断网时，CS 端能不能脱机记账、恢复后自动补传？"能答出本地暂存 + 断点续传设计的，中间件层才算真正落了地；答不出的，多半是把浏览器页面套了个壳。

三、模块划分：参考结构与内聚原则

按第五篇的全生命周期主线，应用服务层的模块划分参考如下：

档案中心：模具台账、图文档案、BOM/型腔结构、编码规则；
库存事务：入库、领用、归还、调拨、封存、报废，全部走"事务单据"而不是直接改库存状态；
计划与执行：保养计划、点检、维修工单、备件联动；
寿命与预警：冲次累计、寿命模型、四级阈值、锁机门禁；
集成中心：ERP/MES 主数据同步、上机校验接口、异常池；
系统内核：组织权限、审计、字典、流程引擎。

两条内聚原则值得写进设计规范。第一，状态变更只走单据：任何模块想改模具状态，必须通过库存事务或工单，禁止绕过单据直接 UPDATE 状态字段——这是第十八篇要讲的"账实不符"问题的架构级预防。第二，预警计算与业务执行分离：规则引擎负责算"哪些模具该预警了"，业务模块负责"生成保养单/发消息/锁机"，两者通过事件解耦，改阈值策略不用动工单代码。