我在快消渠道数字化一线做架构落地多年，一个反复被验证的认知是：B2B订货系统表面是个"门店下单前台"，背后却牵动整套渠道中台。它能不能成，不只看前端体验，更看架构边界划得清不清、数据模型稳不稳。下面从技术管理视角，聊聊它的架构与数据模型。

一、先划清边界：它不属于后台

很多企业在做渠道数字化时，习惯把订货塞进 ERP 或自建 OM。但二者的职责边界不同：

• ERP 与供应链中台负责企业内部的财务、库存、采购，是"算与送"的中枢；
• 订货系统负责企业外部、面向百万级小b端（终端门店）的交易触点，是"接单"的入口。

把外部高频、政策复杂、终端碎片化的交易触点压进内部稳态系统，往往导致迭代僵硬、策略难以下沉。合理的做法，是让订货系统作为独立的交易域存在，通过接口与 ERP/经销商中台协同：订货系统接单并校验，下游负责库存、排线、发货与回写。

二、分层架构

我通常按四层来组织：

1. 接入层：App / 小程序 / H5，面向店主，提供目录浏览、加购、下单、对账。
2. 交易层：商品目录、促销引擎、订单服务、信用与额度、智能补货推荐。
3. 协同层：与拜访管理、经销商管理、促销费用打通，形成"拜访—订货—履约"的 RTM 闭环。
4. 底座层：对接 ERP、数据中台，负责库存核算、经营分析与终端画像。

架构上的关键决策是：促销引擎、客户专属价、起订量规则必须前置到交易层，在提交订单前完成校验，而不是事后在 ERP 里纠错——这正是降低错订漏订的工程抓手。

三、核心数据模型

终端、商品、订单、促销是四个主干实体：

• 终端（store）：门店主数据，含区域、门店类型、店主账号、信用额度。小b端按类型（便利店/夫妻店/母婴店等）差异很大，目录与价格要按类型和区域维度可见。
• 商品目录（catalog_item）：sku 与门店类型、区域的可见关系，承载客户专属价、起订量、箱规、库存。箱规是关键——下单数量必须是起订量的整数倍。
• 订单（order / order_item）：主表记状态机（待审→已审→已发→已签），明细记 sku、数量、单价。状态变更需与下游履约系统事件对齐。
• 促销（promotion）：按门店/区域/品类配置规则表达式（搭赠、满减），在加购环节即时计算。

下单服务在落单前要做四类校验：箱规倍数、库存、客户价口径、信用额度。校验前置能把"人转译人"的出错环节彻底移除。

四、履约协同与事件流

订单提交后，状态流转应与经销商中台、ERP 通过事件对齐：

下单(已校验) → 推送下游生成发货单 → 排线配送 → 门店签收
   → 回写履约状态 → 更新终端画像 → 数据中台汇总

这里最容易出问题的，是状态不一致与对账摩擦。我的经验是：以订单领域事件为单一事实来源，下游履约状态只做只读投影，对账以交易域为准，避免多处口径打架。

五、智能化放在哪一层

智能补货与推荐依赖终端动销数据，应放在数据中台之上、交易层之下：数据中台产出门店动销画像与补货建议，交易层在加购时透出。前提是先积累足够动销样本，过早上 AI 反而干扰门店。

六、落地节奏的管理建议

从架构治理角度，我建议：先以单区域/单品类试点，跑通"浏览—下单—履约—对账"闭环并验证状态一致性；再打通拜访、经销商、促销的数据互通，防止新竖井；最后再叠加智能推荐。每一步都要有明确的接口契约与回写机制，而非功能堆叠。

七、数据一致性与灰度策略

技术管理上还有两件事必须前置考虑。

数据一致性：订单状态在订货系统与下游履约系统之间最容易漂移。我的做法是让订货域持有订单全生命周期的事件流，下游只做只读投影，对账以交易域为准，杜绝多处口径打架。促销费用的核销也走同一事件源，避免财务与业务各算一本账。

灰度策略：终端差异极大，不宜全量切换。我通常按"区域→品类→门店类型"三级灰度：先单一区域跑通闭环，再扩品类验证目录与价格口径，最后按门店类型细化起订量与箱规。每一级都要有明确回滚条件与监控指标（如下单成功率、校验拦截率、对账差异率）。

这两件事决定了系统上线后是"能跑"还是"跑得稳"。架构治理的重心，从来不是功能堆叠，而是边界、契约与一致性。

总结一句：订货域的架构难度不在功能，而在边界与一致性。把这两件事想透，落地就顺了；想不透，功能堆得再多也会在协同处漏水。

作者长期从事快消渠道数字化与企业架构实践，本文为技术落地总结。