商品系统设计(二) - 完整的商品系统

拥有组织结构的商品系统

随着线上的销量越来越多，四兄弟拍板决定要开分店。但是这个又给小D带来一些问题，现在商品里没有店的概念，该如何去支持呢?

首先小风想到的是，直接在商品上增加一个门店id，即如下的设计。

这样子就可以将商品进行分别管理，分别管理商品的状态、渠道等信息。但是会带来一个问题，就是一个商品的某些信息是一样的，比如商品的名称、图片等，但是因为这个设计的原因，导致变成了两个商品。
从维护和管理上都变得更加复杂，而要改进这个设计，需要回答好两个问题:

1. 组织结构会承担哪些与商品有关的职责
2. 组织结构之间的关系如何与商品结合

对于门店，我们这里抽象称为组织结构。

对于问题1来说，简单来讲就是管理商品和销售商品。这就代表商品会有部分的属性落在组织架构上，销售商品则需要一个相对较完整的商品信息。管理和销售两个方便包括的商品信息应该是不一致的，这就是后面我们会涉及的商品读写架构，这里先不展开讲。

对于问题2来讲，因为我们只涉及到了管理和销售，所以我们从这两个方面出发，管理肯定是支持多个层级的，这样才可以比较好的支持扩展。对于销售来讲很简单，一般会是组织结构的叶子节点，可以读取到一个完整的商品信息即可。

回答完上述问题，我们就可以把组织架构融入到商品系统中。

在商品读取的时候就可以选择就近原则，以继承的方式向上读取。

当然也可以采用冗余的方式去做，是一致性和读复杂度的取舍。主数据还是要以Product为准。

总结一下，与上章的渠道一样，组织结构在另外一个维度上提供了商品个性化的管理控制能力，属性要不要下放，下放到哪个层级都是具体的业务需求控制的。这里只是做了一个最简单的例子，来说明商品如何包含组织结构。

扩展阅读: 美团为什么都是门店商品模型，没有商品这一层?

从作者的理解上看有两方面的原因。

首先，业态上也和电商模式会有所区别，基于线下位置的去经营，更应该因地制宜，每个门店商品信息从品类到信息上都有很大的区别。
其次，美团的客户是中小门店，业务规模程度决定改了复杂度不会很高，在这个基本设计的前提下，美团将下发、门店选品这些商品与组织之间的联动给省略掉了，使用批量编辑的方式来更改统一商品维度的信息。
​

可批量管理的商品系统

随着商品越来越多，小C发现有点管理不过来，而且有点麻烦。于是他想不能不能多找两个人进行管理呢，而且每个人负责的商品类别是不同的。现在商品上的属性越来越多，但并非每个商品都需要，例如水溶性VC，百岁山都需要填写容量、能量等信息。有一些信息其实多个商品可以共享，于是就向小D问，这有办法实现吗?

这应该是先把商品的通用信息提取出来，单独维护吧? 小D问到。
小明说对对，差不多就是这个意思。
这就是要一个可批量管理的商品系统吧？
小明: 是的。

按照惯例，小风还是先需要画出一下用例图。在老板的需求上，支持扩展。

在此用例图基础上，首先分为前台分类和后台分类。前台分类主要是为了给客户提供促销和搜索的路径，后台分类主要负责商品商品属性的管理。在这里可以分为可覆盖的属性和不可覆盖的属性。这里我们重点看后台分类，前台更多的和销售有关。以下分类简称类目

那么设计就很简单了，在商品上增加类目id和相应的类目属性即可。

扩展阅读1 - 类目分类

类目属性分类在电商系统中，类目属性包括四种: 规格参数、扩展属性、销售属性。之所以对类目属性区分，主要是功能用途不同。规格参数，用于搜索和商祥下面的规格参数标签页展示; 扩展属性用在商详中的商品介绍标签页中; 销售属性主要用于定义sku，用于定义product下面的sku。
​

扩展阅读2 - 类目为什么是多级

​

目系统为什么看到的都是多级这里首先要区分两个做法。
属性商品都在叶子类目上： 父类只是作为了一个树形结构的节点，没有业务作用，主要的作用是简化寻找商品路径的作用。因为当商品逐渐增多，如果没有多级类目，那么类目下商品会很多，管理起来会很麻烦，打破了类目设计的初衷。
属性不限制在叶子类目阶段: 父级类目开始参与业务作用，从一定程度上可以简化业务管理，但是会带来更多的复杂度。

两种做法哪种更合理呢? 我们从类目的作用去分析，类目的作用在于提供商品聚类的信息，那么在前端C搜索和后端B读的时候，都需要读取到每级类目的属性，而商品一般都挂在叶子类目下，所以搜索通常的做法都是按叶子类目去搜索商品，所以无论属性是否限制在叶子类目上，读取的时候都需要能够读取到，这个合理性的问题也就变成了一个复杂度的问题。因为类目是随着商品的增多而细化，所以在长期看两个都会存在。作者认为属性不在叶子类目上是一个中间状态。

​

智能化的商品系统

小C在管理商品系统的过程中，会发现销售状态的管理很复杂，今天这些该上架了，明天他们该下架了，这些看起来好像是有一些规则的，那么是否系统是否可以帮得上呢?

在商品领域中，大多是静态的基本数据，少部分比较动态的是商品状态，包括数据状态、上下架状态。数据内容看起来是比较少，但是如何去管理该不该有效、该上架还是下架？ 尤其上下架状态作为一种销售计划，牵扯的因素主要是商品类型、时间、库存。而这几个因素中，尤其是库存的因素变化很频繁，很难使用人工的方式进行管理。

如果将商品的销售周期看做商品存活的生命，那么使用生命周期管理的名字就再合适不过。

要做到商品的生命周期管理，可以从以下几个步骤实现:

1. 区分商品的类型，不同类型的销售计划差别很大。
2. 定义各种类型的生命周期各个阶段
3. 定义阶段之间的流转条件及后置动作
4. 使用状态机进行实现。

偏业务的部分比较多，只能从比较大纲的方式去说明。而状态机的技术也比较成熟。这里不再详细介绍。

智能化运营是业务人员减负的重要工具，从这里我们也可以窥探到一些未来商品系统的场景，运营工作中人更多的是决策部分，随着智能化的提升，需要做的决策也会越来越少，开始转向创造规则。
​

​