3. 批次追溯体系架构设计：分层架构与核心模块划分
批次追溯体系并非单一功能模块，而是一个需要与供应商交付流程深度耦合的系统工程。本章从分层架构和核心模块两个维度，拆解追溯体系的技术骨架与业务逻辑，确保每一批物料从供应商发货到入库上架的全链路可查、可追、可控。
3.1 分层架构设计：数据层、业务层、展示层
采用经典的三层架构，将数据存储、业务逻辑与用户界面解耦，便于后续扩展与维护。各层职责与交互关系如下图所示：
架构设计要点：数据层只负责存储与检索，不包含任何业务判断；业务层不直接操作数据库，通过数据访问接口（DAO/Repository）与数据层交互；展示层仅做数据渲染与用户交互，不处理追溯逻辑。这种分层方式在供应商批次追溯场景中，可有效隔离因供应商接口变更或数据格式调整带来的影响。
3.2 核心模块划分
基于三层架构，将批次追溯体系拆解为六个核心模块，每个模块对应一组独立的业务能力。模块划分与职责如下表所示：
| 模块名称 | 所属层级 | 核心职责 | 关键数据实体 |
|---|---|---|---|
| 批次主数据管理 | 数据层 | 维护批次号编码规则、供应商批次映射、物料批次属性 | batch_master, supplier_batch_map |
| 交付记录采集 | 数据层 | 接收供应商发货通知、ASN、物流轨迹、到货扫描数据 | delivery_record, asn_header, scan_log |
| 追溯链构建引擎 | 业务层 | 根据批次号与交付节点，自动生成正向/反向追溯链路 | trace_link, node_relation |
| 异常判定与预警 | 业务层 | 基于预设规则（如批次过期、数量偏差、质检不合格）触发预警 | alert_rule, alert_log |
| 供应商交付看板 | 展示层 | 实时展示批次交付状态、异常分布、供应商交付绩效 | dashboard_config, view_cache |
| 追溯查询与导出 | 展示层 | 支持按批次号、供应商、物料、时间范围多维度检索与报表导出 | query_template, export_log |
3.3 核心模块间协作流程
六个模块并非孤立运行，而是通过数据流与事件驱动形成闭环。以下流程图展示一次典型的供应商交付追溯场景：
协作流程说明：供应商发货后，①交付记录采集模块接收ASN与到货扫描数据；②批次主数据管理模块根据物料编码与供应商代码，自动匹配内部批次号与供应商批次号；③追溯链构建引擎将批次号与收货、质检、入库各节点关联，生成完整追溯链路；④异常判定模块扫描链路中的异常节点（如超期未检、数量不符），触发预警；⑤看板模块实时展示异常批次与供应商交付状态；⑥质量或仓库人员通过查询模块进行深度追溯与报表导出。
3.4 模块间接口规范
为确保各模块在分层架构下独立演进，定义以下核心接口规范：
| 接口名称 | 调用方 | 提供方 | 协议/格式 | 典型响应时间 |
|---|---|---|---|---|
| BatchMatch | 交付记录采集 | 批次主数据管理 | REST/JSON | < 200ms |
| BuildTraceChain | 追溯链构建引擎 | 批次主数据管理 | gRPC/Protobuf | < 500ms |
| EvaluateAlert | 异常判定与预警 | 追溯链构建引擎 | 消息队列/JSON | < 1s（异步） |
| GetDashboardData | 供应商交付看板 | 异常判定与预警 | REST/JSON | < 1s |
| ExportTraceReport | 追溯查询与导出 | 追溯链构建引擎 | REST/CSV或PDF | < 3s（1000条以内） |
接口设计避坑：避免在展示层直接调用数据层接口，防止因数据库结构变更导致前端崩溃。所有跨层调用必须经过业务层封装。对于供应商批次号与内部批次号的映射，建议使用缓存（Redis）减少数据库查询压力，缓存失效时间设置为 30 分钟。
3.5 架构设计检查清单
在落地批次追溯体系分层架构时，建议逐项核对以下要点：
- 数据层：是否已建立批次号唯一索引？供应商批次号是否允许重复？历史数据归档策略是否明确？
- 业务层：追溯链构建算法是否支持正向（从供应商到产线）与反向（从成品到原料）双向追溯？异常规则是否可配置？
- 展示层：看板数据刷新频率是否满足实时性要求？查询接口是否支持分页与条件过滤？
- 跨层通信：是否统一使用 API 网关或消息队列？接口版本管理策略是否已定义？
- 安全与审计：批次数据修改是否有操作日志？供应商是否只能查看自身交付数据？