组合型商品模型设计：从“组合售卖”到“可计算交易单元”的领域建模与工程实践

目录一、为什么组合型商品不应只是“商品数组”（一）业务表象背后的模型分裂1、固定组合：用户买的是一个交易对象，系统履约的是多个明细2、可选组合：用户买的是一个套餐协议，选择结果才构成最终交易实例3、促销组合与交易组合必须分开（二）组合模型的三个核心设计目标1、让组合成为一等公民，而不是基础商品的附属字段2、让规则归规则，价格归价格，库存归库存3、让模型能够扩展，而不是为某一个行业写死二、领域边界与核心概念：先回答“谁负责什么”（一）基础商品、SKU 与组合商品的职责划分1、基础商品负责描述“卖什么类型的东西”2、SKU 负责描述“具体可交易的物料单元”3、组合商品负责描述“如何把多个交易单元组织成新的售卖对象”（二）分组、组合项与选择规则1、分组是规则边界，而不是纯展示分类2、组合项是候选关系，不只是外键3、选择规则需要同时描述基数、数量和条件3.1 基数规则：控制“选多少种”3.2 数量规则：控制“每种选几件”3.3 条件规则：控制“什么情况下能一起选”（三）模型关系与版本：组合商品必须能够冻结过去三、固定搭配与可选套餐：用统一模型表达两类核心场景（一）固定搭配并不需要另一套表1、固定组合可以视为“全部必选、不可取消”的特殊规则2、固定组合是否允许单品独立售卖，应由组件策略决定（二）可选套餐的本质是“约束下的笛卡尔积”1、用户选择形成一个组合实例2、校验应是独立的领域服务3、选择结果要有稳定指纹（三）不要按行业拆模型，要按规则能力拆模型四、价格模型：不要把“组合价”理解成一个金额字段（一）组合价格至少有三种主流计算模式1、固定总价模式2、基础价 + 选项差价模式3、组件合计 - 组合优惠模式（二）价格计算必须输出“价格解释”，而不是只输出结果1、价格明细是售后和审计的基础2、分摊规则必须稳定且可重算（三）组合价格与外部促销要有明确边界五、库存与可售：组合库存通常是派生能力，不是一个静态数字（一）固定组合库存可以由组件库存推导1、组合理论库存等于最稀缺组件可组成的套数2、共享组件会放大竞争关系（二）可选套餐的可售性是“规则满足性 + 候选库存”的联合判断1、分组层面需要判断是否仍存在合法选择2、详情页可售与下单可售要分成两级（三）库存预占要围绕最终组件清单执行六、下单与订单展开：把“售卖视图”与“履约视图”分开（一）订单必须保存交易快照1、组合配置快照回答“用户当时买了什么”2、SKU 快照回答“当时如何履约”（二）一个组合订单可以有多种履约模式1、整体履约2、组件履约（三）售后策略必须在建模时提前考虑七、一致性与分布式交易：组合订单是典型的跨服务工作流（一）下单前的验证应当有明确顺序1、先验证结构，再计算价格，最后占库存2、所有关键步骤都要携带版本或签名（二）跨服务失败不能依赖数据库回滚解决1、使用补偿思想处理已完成步骤2、需要定义“不可逆点”（三）幂等与事件可靠性是工程底座1、每个写操作都要有业务幂等键2、状态变更与事件发布不能出现中间空窗八、生命周期与治理：组合商品不是配一次就永远有效（一）草稿、已发布、下线是最低限度的状态机1、编辑和发布要分离2、生效时间可以让配置变更可计划（二）组件变化需要明确影响策略1、基础 SKU 下架不应自动删除组合关系2、组件价格变化是否影响组合，要由计价模式决定3、组件属性变化需要区分“展示变化”和“交易变化”（三）审计、权限与风险控制应该成为发布链路的一部分九、数据结构与 API：让约束在数据库与服务层同时生效（一）关系型数据结构建议1、核心表拆分2、数据库约束用于阻止最基础的数据错误（二）面向详情页的读模型应该预聚合1、交易模型不等于页面查询模型2、读模型可以失效重建，但权威模型必须可追溯（三）写 API 应围绕领域动作设计1、避免一个“万能更新接口”2、发布接口应该返回完整校验结果十、性能、缓存与搜索：不要让组合关系成为新的查询放大器（一）缓存粒度以“组合版本”优于“组合 ID”（二）搜索索引要明确“搜组合”还是“搜组件”（三）高并发场景优先做“批量依赖查询”而不是“大缓存对象”十一、测试体系与可观测性：复杂规则必须被机器证明得足够多（一）规则测试要覆盖边界，而不是只测正常路径1、基数与数量组合测试2、依赖规则要做不可满足检测（二）契约测试和端到端测试要覆盖跨域快照1、商品到订单的契约必须稳定2、端到端测试重点覆盖变更时序（三）可观测性应围绕“组合实例”建立关联十二、从旧系统迁移：不要试图一次性重写全部商品链路（一）第一阶段：先抽象组合结构，保持交易链路尽量不动（二）第二阶段：把价格、库存从组合配置中解耦（三）第三阶段：引入版本、事件与异步读模型十三、常见失败方式与设计审查清单（一）七类高频反模式1、把组件列表直接塞进商品扩展字段2、为每一种可选结果预生成一个 SKU3、给组合维护独立库存，同时又扣组件库存4、在订单里只保存组合 ID5、把促销和组合内生价格混在同一个计算器里6、前端校验通过就直接下单7、组合发布直接覆盖线上记录（二）设计评审时可以逐项确认的十个问题十四、结语：真正稳定的组合模型，是把不确定性留在规则层，把确定性带入交易层延伸阅读与参考资料干货分享，感谢您的阅读！组合售卖看起来只是“把几个商品放在一起卖”，但当系统真正进入价格、库存、下单、履约、售后、搜索、促销与风控链路后，组合商品会迅速从一个前端展示功能演化为跨域交易模型。把常见组合场景抽象为“固定搭配”和“可选套餐”，并在基础商品模型之上引入组合商品、分组与分组关联等概念。本文在此基础上进一步扩展：不再把组合商品理解为一个保存若干商品 ID 的容器，而是把它定义为具有独立售卖身份、规则语义、价格语义、库存语义和订单快照语义的“可计算交易单元”。我们从领域边界、规则建模、价格、库存、订单、分布式一致性、生命周期、数据结构、缓存、测试与迁移等方面给出一套可落地的工程方法，并说明固定组