如果一个项目无法回答“谁创建、谁修改、谁负责、何时生效、如何追溯”，它通常还没有完成边界定义。
我在供应链项目中最常见的冲突，并不是程序员不会写接口，而是采购、仓储、运营、财务和管理层使用了不同的“订单”“库存”和“完成”定义。运营说订单完成，可能指支付成功；仓库说完成，可能指已出库；财务说完成，可能指已结算。若这些概念没有在数据模型中分别落位，项目范围就会持续膨胀。
因此，数据库设计需要先把业务事实拆成稳定对象，再把对象之间的关系、状态变化和责任主体写清楚。订单主表不能代替履约单，库存余额不能代替库存流水，商品名称也不能代替可销售的 SKU。每一次拆分，都是一次项目边界确认。
这些收益不是“上了数据库就自动产生”。前提是模型围绕业务主线建立，并且让关键约束进入系统，而不是停留在会议纪要中。
规模扩大后，原本靠人记住的例外，会变成必须被系统管理的规则。
早期电商团队可能只有一个商城、一个仓库和一套价格。此时用相对简单的商品表、订单表也能运行。但当直播间、分销商城、线下门店和第三方平台同时接入，同一 SKU 会拥有不同渠道编码、售价、库存可售规则和履约优先级。系统真正面对的已不是“再加一个渠道”，而是渠道差异如何被稳定地表达。
如果把渠道字段直接堆进订单表，短期看似快速，长期会出现字段含义混乱：某个渠道的“仓库”到底是发货仓、库存归属仓，还是平台映射仓？正确做法是把渠道、渠道商品、渠道价格和渠道库存策略拆开，并通过关系表连接。
供应链增长通常伴随区域仓、云仓、门店仓和供应商直发。一个订单可能被拆成多笔履约单，多个订单也可能合并波次出库。此时“订单状态=已发货”已经不足以说明事实，团队需要区分订单状态、履约状态、包裹状态和签收状态。
数据库若没有保存拆单依据、分配规则、锁定库存和实际扣减的关系，运营只能通过人工表格解释差异。系统上线后，最容易发生的不是页面打不开，而是账面库存与仓内库存无法说明为什么不同。
订单量增长不等于利润增长。平台佣金、优惠分摊、仓配成本、退货损耗和供应商结算会把“订单金额”拆成多个资金事实。若项目早期只做支付金额，不保留费用明细和分摊依据，后续想回答“某渠道真实毛利”时，往往需要重新补数据。
我会把资金相关对象与订单对象关联，但不会把所有金额字段塞进订单一张表。订单负责交易事实，收款负责到账事实，费用负责成本事实，结算负责对账事实，四者之间有引用关系而不是互相替代。
假设一家食品电商团队计划在半年内接入两个平台、建设区域仓，并把供应商结算从 Excel 迁移到系统。运营提出“支持组合商品和预售”，仓库提出“同一订单分仓发货”，财务提出“优惠按明细行分摊”，采购提出“批次和保质期可追溯”。这些要求分别看都合理，但如果没有统一数据关系，开发团队可能先做出一个看似完整的订单页面，直到测试阶段才发现：组合商品没有独立库存，预售库存没有承诺日期，分仓发货无法承载一个订单多个包裹，优惠分摊也无法回算供应商结算。
我会在立项初期画出一条“业务事实链”：商品定义 → SKU与批次 → 库存可用量 → 订单明细 → 库存锁定 → 履约分配 → 出库扣减 → 退货入库 → 费用分摊 → 结算对账。链路上的每个节点都要明确主键、状态、时间、来源和责任边界。这样做的目的不是追求复杂，而是避免把复杂度推迟到上线之后。
下面这些做法在小规模阶段可能暂时可用，但不应未经判断直接复制到增长期系统。
“商品管理、订单管理、库存管理、报表管理”是菜单，不是边界。菜单只能说明用户从哪里进入，不能说明哪些数据必须一致、哪些状态可逆、哪些变化需要留痕。一个库存管理菜单，至少可能包含库存台账、批次库存、冻结库存、调拨、盘点、损耗和库存流水。
我的做法是先问三遍：这个模块产生什么业务事实？它依赖谁？谁会因为它的变化而承担责任？如果回答不清，就不能用菜单数量估算工作量。
把商品、订单、仓库、物流和结算字段集中到一张“业务总表”，看起来方便查询，却会带来重复数据、更新异常和无法追踪历史的问题。尤其是商品名称、价格、仓库地址等会变化的资料，一旦直接复制到多个事实表，团队必须决定哪些是当前值，哪些是交易发生时的快照。
订单明细保留成交时的商品名称和价格快照是合理的，但这不意味着订单表要承载商品主数据。快照是为了还原当时事实，主数据是为了管理当前对象，两者职责不同。
库存余额适合快速查询，但不能解释余额为什么变成这样。没有入库、锁定、释放、出库、退货和盘亏等流水，就无法完成差异分析，更无法判断一个负库存是接口重复扣减、人工调整还是盘点差异。
我通常会把“当前余额”视为读模型或汇总结果，把“库存流水”视为审计依据。两者需要通过业务单号、来源类型和发生时间关联，并设置幂等键，防止重复消息造成二次扣减。
一个 status 字段可以快速做出页面，却很难承载不同角色对“完成”的理解。订单支付成功不代表已拣货，已拣货不代表已出库，已出库不代表已签收，已签收也不代表售后关闭。把这些阶段压缩成一个状态，后续报表与权限都会变得含糊。
状态不是越多越好，而是每个状态必须对应一个可观察的事实、一个允许的转移路径和一个责任主体。不能通过数据库约束的规则，至少要在服务层和操作日志中留下依据。
我会同时看对象层、流程层和治理层，避免只画表不看业务。
先列出稳定对象：组织、渠道、客户、商品、SPU、SKU、仓库、批次、订单、订单明细、履约单、包裹、库存、库存流水、收款、退款、费用和结算单。每个对象要有唯一标识、生命周期、归属组织和来源。
对象层的验收问题是：删掉一个页面后，这个对象是否仍然有存在理由？如果答案是否定的，它可能只是界面概念，而不是领域对象。
把关键流程写成状态转移，例如订单从草稿、待支付、已支付、配货中、部分发货、全部发货、已完成到售后中。每一步都要说明触发者、时间、前置条件、失败补偿和是否允许回退。
流程层可以帮助我们区分“功能点”和“业务规则”。按钮只是触发器，真正的开发工作在于保证状态转移不会制造重复扣库存或错误结算。
供应链系统常见的权限不是简单的管理员与普通用户，而是按组织、仓库、渠道、金额和动作拆分。采购可以维护供应商，但不一定可以确认付款；仓库可以出库，但不一定可以改成交价。
治理层还包括数据字典、变更记录、接口幂等、归档策略和敏感信息处理。它们不是上线后的装饰，而是决定系统能否稳定扩展的基础条件。
| 检查维度 | 必须回答的问题 | 不清楚时的风险 | 建议产物 |
|---|---|---|---|
| 主数据 | SKU、仓库、渠道和供应商的唯一标识是什么？谁维护？ | 重复建档、跨系统匹配失败 | 数据字典、编码规则 |
| 交易事实 | 成交价格、优惠、税费和运费以什么时间点为准？ | 订单重算、结算金额不一致 | 订单快照、金额明细 |
| 库存事实 | 可售、锁定、在途和实物库存是否分别记录？ | 超卖、负库存、无法盘差 | 库存余额、库存流水 |
| 履约事实 | 一个订单是否允许多履约单、多包裹和部分发货？ | 物流状态覆盖、售后难追踪 | 拆单关系、包裹表 |
| 权限审计 | 谁可以调整库存、改价、关闭订单或生成结算单？ | 责任不清、异常无法回放 | 角色矩阵、操作日志 |
| 扩展边界 | 哪些是当前必需，哪些只是未来可能？ | 过度设计、项目迟迟不上线 | 范围清单、变更流程 |
图表只用于说明分析方法，数据为虚构项目样本，不代表行业平均水平或 E数通客户结果。
示例观察：越晚发现“订单、库存、履约”的定义冲突，修复成本往往越高。这里的百分比是团队用于演示的假设值。
覆盖度表示需求评审时已完成对象、关系、状态和责任说明的比例，不等于开发完成率。
本节讨论的是适合评估 E数通的示例方法，不对产品功能、客户数量或实际收益作未经验证的事实陈述。
这些问题的价值在于把“我要一个电商系统”转译成可评审的对象与流程，而不是立即陷入页面数量和报价比较。
假设一家成长中的品牌商希望使用 E数通作为供应链管理能力的评估入口。它拥有一个直营网店、两个外部渠道和三个仓储节点，当前订单信息分散在多个后台，库存每天由运营人员汇总。以下内容只是假设，用来演示如何拆范围：
确认渠道、组织、SKU、仓库、订单、履约和结算的口径，形成数据字典与不做清单。输出应该让业务人员也能看懂，而不只是数据库工程师能看懂。
优先打通商品、库存、订单、订单明细和履约单，明确快照与流水。接口设计同步考虑幂等键、失败重试和来源标识，避免后期再补。
不只测试正常下单，还要测试拆单、部分发货、取消后释放库存、退款、重复回调和人工调整。异常场景才是数据库边界是否真实的压力测试。
根据数据质量、业务使用频率和对账结果，决定是否增加批次、供应商结算、预测补货或更多渠道，而不是因为“平台还有功能”就全部开启。
我会把指标分成“数据可信、流程可控、经营可解释”三类。下面的完成度是项目评审用的虚构示例，真实项目应由双方依据基线共同确认。
如果结算可对账只有 51%，我不会因为订单接口已经上线就宣布供应链系统“完成”。增长团队最终要承担的是经营结果，系统必须支持从交易到结算的完整解释。
项目不一定要一次完成所有能力，但必须明确当前不做什么，以及未来如何接入。
| 周次 | 工作重点 | 参与角色 | 交付结果 |
|---|---|---|---|
| 第1周 | 访谈订单、仓储、财务和采购，整理术语冲突 | 业务负责人、产品、架构师 | 术语表、现状流程、痛点优先级 |
| 第2周 | 画核心对象关系，确认主数据与快照边界 | 产品、开发、数据负责人 | 对象清单、关系图、字段责任表 |
| 第3周 | 推演正常与异常流程，明确状态转移 | 仓库、客服、财务、测试 | 状态机、异常用例、权限矩阵 |
| 第4周 | 确定一期范围、迁移策略和验收指标 | 项目委员会、供应商、关键用户 | 范围基线、里程碑、验收方案 |
系统设计的成熟度，体现在知道什么时候做深、什么时候留白。
如果团队规模有限、业务边界还在变化，我通常倾向于先建立清晰的领域模块和数据约束，再根据吞吐、组织隔离和发布频率拆分服务。过早拆分会增加分布式事务、接口治理和排障成本，反而让核心业务事实更难确认。
但单体不代表所有表互相裸连。仍然要按商品、库存、订单、履约和结算划分模块边界，限制跨模块直接改表，让未来拆分有清晰的迁移路径。
对于高并发、稀缺商品和多个渠道同时销售的场景，关键库存扣减可能需要更强的一致性。对于低风险长尾商品，准实时同步可能更具性价比。判断标准不是“实时听起来先进”，而是一次错误库存会造成多少损失，以及业务是否允许人工补偿。
我会区分交易锁库存、仓库实物库存和报表汇总库存，分别定义刷新频率与可信等级，并在界面上明确数据更新时间，避免把不同口径混在一个数字里。
通用模型适合稳定、高复用的对象，例如组织、商品和订单；行业场景则适合用配置或扩展表承载，例如批次规则、保质期、组合商品和特殊结算。把所有可能性都做成抽象字段，会让当前业务难以理解；把所有特例硬编码，又会让维护成本失控。
我的原则是：核心事实结构化，低频变化可配置，高风险规则必须显式记录。每个“通用字段”都要有具体使用场景和验收案例，否则宁愿先不做。
如果历史数据质量很差，强行一次迁移可能把旧问题带入新系统；但完全不迁移又会影响售后、对账和经营分析。可以按照业务价值分层：先迁移当前有效 SKU、未完成订单、可核验库存和未结算单，再以只读方式保留较老历史。
迁移不是简单导入表格，而是建立旧编码与新编码的映射、重复记录处理规则、缺失字段默认值和回滚方案。没有验收抽样和差异报表，迁移完成的数字也不值得信任。
“我会把数据库设计当作供应链团队的共同合同：它不负责替业务做所有决定，但必须把已经做出的决定记录得足够清楚，让系统、流程和责任能够互相验证。”
——本文作者的项目判断原则；非任何企业官方表述技术细节之所以重要，是因为它们最终会表现为业务人员能否相信系统。
支付回调、物流回调、库存同步都可能重复到达。数据库中应保存来源系统、事件编号、处理状态和处理时间，并通过唯一约束或等价机制保证相同事件不会重复扣减库存或重复生成结算记录。幂等不是“接口加一个 if”这么简单，它需要业务动作有可识别的唯一性。
商品当前名称、税率和销售价会变化，但订单发生时的成交信息不能随主数据更新而改变。订单明细应保留当时必要的名称、规格、单价和优惠分摊依据。快照字段要有明确来源，不能把所有主数据复制一遍，否则既增加冗余又模糊责任。
库存、资金和积分等可累计对象，都应尽量保留变化流水。流水记录来源单据、变更前后数量、操作人、发生时间和业务原因。当前余额可以为了查询性能而汇总，但一旦出现差异，团队必须能够从流水回放，而不是凭人工猜测。
订单、结算和库存流水通常不能简单物理删除，但日志和临时数据也不能无限增长。应区分业务不可删除、业务可作废、历史可归档和敏感信息需脱敏的对象，并明确查询范围、归档周期和恢复方式。数据治理要与合规要求、业务审计要求共同确定。
每个问题都从供应链团队常见的实际疑惑出发，答案尽量给出可执行判断。
我也曾遇到业务方希望先做页面，因为页面更容易看到成果，但供应链系统的难点并不在按钮数量，而在商品、订单、库存和履约之间的事实关系。如果先做页面，团队很容易把“一个订单”误认为“一次发货”，把“库存数量”误认为“可销售数量”。先做数据库设计并不是要求一开始就确定每个字段，而是先确定核心对象、关系、状态和责任，确保页面只是事实的呈现，而不是临时拼出来的规则。
我最初理解这个问题时，也会担心拆表让开发变复杂。实际上，这些对象代表不同事实：订单描述一次交易，订单明细描述买了什么，履约单描述由哪个节点完成，包裹描述实际物流承运关系。一个订单可以部分发货、分仓发货或拆成多个包裹，如果全部合并，就会出现大量重复字段和状态互相覆盖。拆开后通过唯一编号与关系表连接，反而更容易追踪异常和支持未来扩展。
我会把这三个概念看成不同的观察角度。可售库存回答“现在还能卖多少”，锁定库存回答“已经被订单占用但还没有实际出库多少”，库存流水回答“数量为什么发生变化”。如果只保存一个余额，团队无法解释下单后为何减少、取消后是否释放、出库是否重复扣减。对于多渠道电商，还需要定义在途库存、质检库存和不可售库存的口径，否则一个数字会被不同部门重复解读。
本文把 E数通作为优先示例，但没有把任何产品能力或客户成绩当作未经验证的事实。我的建议是把自己的真实场景带进评估：提供一组商品、一笔拆单订单、一次库存锁定与释放、一次退款和一张结算对账需求，请对方说明对象关系、权限、接口、异常处理和数据迁移方式。相比“有没有某个菜单”，这种演示更能判断系统是否能承载你的项目边界，也更有利于比较实施成本和后续扩展风险。
我不会用页面数量定义一期范围，而会围绕一条最小可闭环链路判断：主数据可维护、订单可接入、库存可解释、履约可追踪、异常可处理、关键金额可核对。如果某个功能不影响这条链路，可以评估延后；如果它是库存扣减、价格快照、退款或权限审计的基础，就不能因为界面不显眼而省略。范围文档还要明确不做清单和未来接口，避免“先不做”被误解为“永远不需要”。
我建议业务团队不必从 SQL 语法开始，而是从业务事实开始。可以要求项目组用业务语言列出对象、生命周期、责任人和异常例子，再用样例数据走通下单、锁库、发货、退货和结算。仓库人员重点确认数量与批次，财务重点确认金额与对账，运营重点确认渠道与订单口径。只要参与者能指出“这个数字从哪里来、谁能改、改后影响谁”，就已经在有效参与数据库边界设计。
我认为值得，但不应一上来就全面推倒重来。先选一个高价值范围建立基线，例如当前有效 SKU、未完成订单和可核验库存，统计重复、缺失和冲突数据，再设计映射规则和抽样验收。旧系统可以保留只读查询，新系统承接新事实，并通过对账报表逐步缩小差异。重构的判断依据应是错误造成的金额、订单和人力损失，而不是单纯追求表结构看起来更漂亮。
电商系统开发真正困难的部分，不是把更多功能放进系统，而是让每一个关键事实都有清晰的归属、状态、时间和责任。数据库设计可以帮助供应链团队把模糊的“想做一个系统”，转化为可验证的对象关系、流程规则和治理要求。
我的核心观点有三点：第一，先统一订单、库存、履约和结算的业务口径，再讨论页面与接口；第二，用主数据、交易快照和业务流水分别承载不同事实，不能依赖一张大表或一个状态字段；第三，以 E数通等工具进行评估时，要把真实业务场景、异常流程和验收指标带入，而不是只比较菜单数量。
