今天老王带着大家深入探讨一个核心概念——商品域 。这并非仅仅指代一个具体的商品管理系统，而是一个涵盖所有与商品相关能力的广阔领域。

正文开始之前，先送个福利，最近老王整理了产品经理免费的教学知识库，关注公众号后，自动回复直接送了！

在很多大厂系统设计中，会将复杂的业务功能按照其内在联系和职责划分成不同的域。

商品域，正是这个理念在零售体系中的重要实践。它不仅仅是我们通常认为的创建商品、编辑商品、管理后台界面那么简单。

一个成熟的商品域，应当是一个通用的、可复用的能力中心，为整个商业体系提供稳定、一致、全面的商品信息和服务。

掌握了领域化的设计思想和商品域的核心模型，才能真正提升我们构建复杂系统的能力，而不是停留在绘制原型和界面的表层。

商品域在交易链路中的位置

为了更好地理解商品域的重要性，我们可以将整个交易流程粗略地划分为三大阶段：售前、售中和售后。

 1、售前阶段：这个阶段的核心是让商品准备好被销售。

• 采购域，商品并非凭空产生。对于非自产商品，我们需要从供应商处采购。采购域负责管理供应商信息、发起采购单、处理采购结算、以及确保商品入库等流程，核心目标是获得商品的货权。

• 价格域 ，商品的价格并非单一固定。基础售价、促销活动价、会员价、渠道价……价格信息可能散落在系统的各个角落。如果缺乏统一管理，当外部系统（如下单、搜索）需要获取一个商品的最终售价时，就会面临困境：该调用哪个服务？哪个价格优先级最高？价格域的使命就是建立一个价格中心，统一管理所有价格类型、计算规则和优先级，对外提供标准、可靠的价格查询服务。

• 优惠域 ，营销活动是促进销售的关键。满减、满赠、优惠券、红包、组合套餐、补贴等都属于优惠域的范畴。它负责创建、管理和执行各种营销策略，并在交易过程中（如下单时）与订单域紧密协作，确保优惠能够准确应用。

 2、售中阶段：这个阶段围绕订单的生成和履行展开。

• 订单域/交易域 ，这是交易的核心环节。它接收来自上游（如购物车、商品详情页）的商品信息、价格、库存、优惠等，生成交易订单。同时，它还需要对接支付系统完成收款，并触发后续的履约流程。广义的订单域还包括正向交易（下单支付）、逆向交易（退款退货）以及履约（发货、核销、安装）等子领域。

 3、售后阶段：交易完成后的相关流程。

• 供应链域 ，主要关注商品的实体流转，特别是从仓库到用户手中的物流过程，这部分与售中阶段的履约域有重叠和关联。

• 财务域 ，负责处理交易完成后的账务结算。例如，需要将订单金额按照商品、优惠、税费等维度进行拆分，生成会计分录，进行对账等。

观察这个流程，不难发现，无论在哪个阶段，商品域都扮演着底层支撑的角色。采购需要知道采购什么商品；价格和优惠需要依附于具体商品；订单需要包含明确的商品信息；供应链处理的是实体商品的流转；财务结算也需要基于商品进行成本和收入的核算。

商品域的核心服务能力

作为一个能力中心，商品域需要向其他领域或系统提供一系列标准化的服务。这些服务构成了商品域对外输出价值的主要形式：

 1、销量服务 ，提供查询特定商品的销售数量、趋势等数据。

 2、促销关联服务，允许通过商品ID反查该商品参与了哪些促销活动，是连接商品域与优惠域的桥梁。

 3、商户服务 ，在多商家平台模式下，需要知道哪些商户在销售某个商品，以及相关的权限和关联信息。

 4、库存服务 ，提供商品的库存查询、预占、扣减、回补等操作接口。这是保证交易顺利进行的关键。

 5、商品管理服务 ，提供商品核心信息（SPU/SKU/Item）的增、删、改、查能力。这是商品域最基础，也是最核心的功能。

 6、运费服务，基于商品的属性（如重量、体积、发货地）和运费模板，计算基础运费。

 7、价格服务，对外提供查询商品各种价格信息（如基础价、市场价）的能力，是价格域能力的透出窗口之一。

 8、搜索服务，商品信息结构化地同步到搜索引擎，提供强大的商品搜索和筛选能力。

通过提供这些标准化的服务，商品域将复杂的商品逻辑内聚，降低了其他系统与之交互的复杂度，实现了系统间的解耦和协同。如果你正在构建或优化商品系统，可以参考这些服务划分，审视自身系统的能力是否完备，逻辑是否清晰。

商品域内部的核心管理功能

了解了商品域的外部服务，我们再深入其内部，看看它需要具备哪些核心的管理功能：

 1、商品创建与编辑，这是基础。需要注意的是，我们通常创建的是一个产品的抽象，即SPU ，它代表了一类商品。在此基础上，再定义具体的规格（如颜色、尺码），形成SKU ，即可销售的最小库存单位。前台用户看到的是SPU，选择规格后加入购物车或购买的是SKU。

 2、类目管理 ，商品需要归属到特定的分类中，便于管理和导航。类目体系的设计至关重要。平台型（特别是对第三方商家开放的）类目通常由平台方严格定义和管理，商家只能在授权的类目下发布商品。自营模式下类目管理相对灵活，但仍需保持结构清晰。前后台类目的映射关系也需要维护。

 3、品牌管理 ，商品通常有关联的品牌。需要建立品牌库。平台可以预设品牌供选择，也可以允许商家申请添加新品牌（需审核）。自营模式下，运营人员创建商品时需要能方便地选用已入库的品牌。

 4、属性管理 ，商品具有各种属性，如规格属性（颜色、尺码）、描述属性（材质、产地）。属性需要与类目关联，即特定类目的商品拥有特定的属性集。属性管理包括属性的定义、属性值的管理等。

 5、SPU/Item/SKU管理：

• SPU管理: 对标准产品单元进行管理，是商品信息的核心载体。

• Item管理: 在某些平台架构中，Item可以理解为商家发布的商品链接或销售单元，它可能对应一个SPU，并包含该商家特定的销售信息（如标题、店铺内分类）。它介于SPU和SKU之间。
  

• SKU管理: 对最小库存单位进行管理，包括库存、价格（基础售价）等关键信息。商品的上下架、启/停用等操作通常也在此层面。

规则管理 ，定义与商品相关的各种业务规则，例如：是否允许预售、下单时间限制、特定的配送方式、支付方式限制、前台展示逻辑（如是否推荐）、特殊资质要求等。这些规则有时也会配置在属性中，但将它们显式地作为规则来管理，有助于逻辑的清晰化。

很多同学可能只接触过上述功能中的一部分，比如商品创建和类目管理。但这只是商品域能力的冰山一角。一个完善的商品域需要覆盖以上所有方面，并确保它们之间逻辑自洽、协同工作。

商品域的核心数据模型

支撑上述功能和服务的是一套精心设计的数据模型。核心数据通常可以分为两大块：

 1、基础数据 

基础数据通常指那些相对稳定、用于定义和分类商品，并被多个商品共享的信息。它们构成了商品管理的基本框架。基础数据表主要包括：

• 类目表 ，定义商品的分类体系，例如“服装 > 男装 > T恤”。这是用户浏览和平台管理商品的基础。

• 前后台类目表 ，有时，面向用户的展示类目（前台）和内部运营管理使用的类目（后台）可能存在差异或映射关系，该表用于管理这种对应。

• 属性表 ， 定义了描述商品特征的“键”，例如“颜色”、“尺码”、“材质”等。

• 品牌表，存储商品的品牌信息。

• 类目品牌关联关系 ，定义了哪些品牌可以归属到哪些类目下，确保数据规范性。例如，某手机品牌只应出现在“电子产品”类目下。

• 类目属性组关联，定义了特定类目下需要关联哪些属性。例如，“服装”类目需要关联“颜色”、“尺码”、“材质”等属性，而“手机”类目则需要关联“内存”、“颜色”、“网络制式”等属性。

 2、商品数据 

商品数据则侧重于描述具体的、可供销售的商品实体信息。这类数据通常变动更频繁，且与库存、价格等直接关联。商品数据表主要包括：

• SPU表 ，SPU代表标准产品单元，是一组具有共同属性的标准化商品集合。例如，“iPhone 14 Pro”是一个SPU，它包含了所有颜色、存储容量的该款手机。SPU本身不直接销售，主要用于聚合信息。

• SPU属性表，存储SPU层级的共同属性值。例如，对于“iPhone 14 Pro”这个SPU，“屏幕尺寸”是所有SKU共有的属性。

• 商品Item表 ，这个表的具体定义可能因系统而异，有时可能指代SPU，或者是一个更通用的商品概念层。从图中看，它处于一个承上启下的位置。

• 商品详情表，存储商品的详细描述信息，如图文详情、规格参数的长文本等，这些内容通常比较大，单独存放可以优化查询性能。

• 商品图/视频关联表 ，管理商品对应的图片、视频等多媒体资源及其关联关系。

• SKU表 ，SKU是库存量单位，是实际进行销售和库存管理的最小单元。每个SKU都具有确定的属性组合。例如，“iPhone 14 Pro - 256GB - 暗紫色”就是一个具体的SKU。

• SKU属性表 ，存储区分不同SKU的属性值。例如，对于“iPhone 14 Pro”这个SPU下的SKU，“颜色”和“存储容量”就是SKU层级的属性。

• 商品属性关联表 ，用于存储SPU或SKU与其具体属性值（来自基础数据中的属性表）的关联关系。

这些表结构及其关系构成了商品域的数据基础。理解了数据模型，也就更容易理解其上层的功能和服务的实现逻辑。表的存在意味着需要相应的功能来维护，功能的设计也需要考虑底层数据的支撑，两者相辅相成。

我们学习商品域，不仅仅是为了知道如何设计一个添加商品的界面，更重要的是建立起一种产品架构师的视角。

..........