★ FEATURED ARTICLE 目录一、商品为什么会长成一团乱麻（一）商品是所有业务系统的公共锚点（二）一张商品宽表的四种典型病症1、模型膨胀2、边界混杂3、能力耦合4、变更失治（三）病根：一个词承载了太多语义（四）实测：一张宽表把库存的高频写传染给了价格二、先画地图：商品供给域的子域划分（一）判定子域的三把尺子1、差异化程度2、变化节奏3、一致性要求（二）核心域：决定“卖什么、在哪卖、卖多少钱、还有没有”（三）支撑域：让核心域更可靠、更好用（四）通用域：所有子域都需要的公共能力（五）子域分类会随业务漂移三、总店商品：标准从哪里来（一）子域定位：定义“它是什么”（二）关键上下文1、商品主数据上下文2、类目与属性上下文3、商品生命周期上下文4、铺货与授权上下文（三）聚合怎么划（四）与门店商品的关系：模板与实例1、三种常见的下发方式2、实测：九十天里三种方式的代价四、门店商品：把标准落到每一家店（一）子域定位：定义“在这里怎么卖”（二）核心上下文拆解1、门店经营范围上下文2、门店商品上下文3、本地化覆盖上下文4、渠道商品上下文（三）可售状态是合成出来的，不是写出来的（四）规模与工程要点1、数据规模与分片2、批量操作与异步化3、上下架的守卫条件五、价格：最容易被低估的核心域（一）为什么价格必须独立建模（二）核心上下文1、价格定义上下文2、调价单上下文3、价格解析上下文4、价格快照上下文（三）设计挑战1、优先级冲突2、生效时间与追溯更正3、交易时刻的价格一致性4、商品价与成交价的边界六、库存：一致性压力最大的子域（一）子域定位：定义“还能卖几件”（二）关键上下文1、库存主档上下文2、库存流水上下文3、可售库存计算上下文4、预占与释放上下文（三）热点扣减：四种方式的实测对比（四）架构原则1、扣减必须是原子的条件更新2、流水是真相，主档是缓存3、库存不承担商品定义和价格4、对交易承诺明确的契约七、支撑域：质量与标签（一）质量子域：让商品“能放心地卖”1、子域定位2、从规则到结论3、按批号而非按 SKU 处置（二）标签子域：不改结构也能贴上新含义1、标签是一种“反模型化”设计2、标签的三个组成部分3、标签治理八、通用域：操作日志与变更通知（一）操作日志：写给人看的记录1、设计目标2、实现要点（二）变更通知：写给系统用的事件1、为什么必须事件驱动2、事件设计规范3、可靠发布：事件表模式4、幂等与乱序：实测三种消费方式九、协同全景：让八个子域重新拼成一个整体（一）一次新品上市的跨子域旅程（二）上下文映射：把关系画清楚（三）写分域、读聚合十、演进路线：从一张宽表走到八个子域（一）四步演进1、统一语言2、模块化单体3、拆数据与服务4、事件驱动与团队对齐（二）常见误区（三）治理机制十一、总结参考与延伸阅读干货分享，感谢您的阅读！做过零售、电商或本地生活系统的人，大概都经历过这样一个场景：产品经理在需求评审会上说“给商品加个字段”，话音刚落，会议室里就分成了好几派。做交易的人问“这个字段下单时要不要校验”，做门店运营的人问“门店能不能自己改”，做搜索的人问“要不要进索引”，做数据的人问“历史数据怎么回填”。一个字段引发半小时争论，最后的结论往往是“先加到商品表里，后面再说”。“后面”通常不会再来。几年下来，商品表长到两百多个字段，一次促销调价能把门店上下架卡住，一次总部改名能把门店手工维护的本地名冲掉，一次库存高峰能让运营同学的批量改价频繁失败。大家都觉得“商品系统太重了”，却很难说清楚它到底重在哪里。这篇文章想换一个角度来回答这个问题。我们拿一瓶最普通的山泉水做例子：在总部的商品主数据里，它是一个 SPU 下挂着的三个 SKU；在城东分号的柜台上，它是一个有本地名、有陈列位、此刻处于上架状态的门店商品；在价格系统里，它同时挂着基础价、区域价、门店价、渠道价和会员价；在库存系统里，它是“实物 1000 件、预占 120 件、可售 750 件”的一组数字；在质量系统里，它是一个需要按批号追溯的检测对象；在标签系统里，它被贴上了“低糖”“夏季热卖”；在审计视角下，它有一长串“谁在何时改了什么”的记录；在集成视角下，它的每一次变化都要通知到十几个下游系统。同一件货，八种身份。商品系统之所以难做，不是因为某个技术点特别难，而是因为这八种身份长期被塞在同一个模型、同一张表、同一个服务里。本文以领域驱动设计（DDD）为方法，把“商品供给域”拆成八个子域，逐一讨论它们的职责边界、核心上下文和设计取舍，并用六组可
阅读完成 · 觉得有帮助？
