Java生鲜电商平台-商品中心的架构设计与源码解析…

2020-03-23 05:36:16来源：博客园阅读 ()

Java生鲜电商平台-商品中心的架构设计与源码解析(小程序/APP)

说明：Java生鲜电商平台中，由于商品的架构很大程度决定了电商的扩展性与伸缩性。对此根据自己多年的生鲜电商经验，整理了以下的商品中心思维导图

对于没有接触过生鲜电商的童鞋，可能对基础类目没什么概念。其实这个东西很好理解，基础类目就是商品属于什么基础分类，是手机，还是平板，还是笔记本电脑，换言之，商品的基础类目就是定义商品是什么。类似于大学中所学的纲科目属。不同的基础类目之间实际上是描述这个类目的特征的不同。

例如

手机这个类目，对应的特征就是：前摄像头像素，后摄像头像素，屏幕尺寸，网络制式等；

而裤子这个类目，对应的特征就是：腰围，裤长，面料材质，厚度等。对于电商，习惯上把描述不同类目的特征称之为属性，每一个类目维护的时候，就要选定该类目的属性，然后新增商品的时候，先选中该商品的类目，则会出现对应的属性供运营者维护。以属性为区分维度建立适合粒度而又不耦合的类目树，串联所有的商品，是商品管理的核心所在。

一个电商APP/小程序的运营后台基础类目树只能有一颗，任一个商品只能属于该类目树上的一个基础类目。具体的类目管理包括：类目节点的新增/编辑/删除、类目节点的排序和类目节点的属性维护。

图片 1

每个平台默认有一颗基础类目树，点击菜单进入该类目树详情页，以选中的“休闲零食”这一节点为例，第一个页签“节点详情”为当前节点的明细，包括三个信息：名称（必填），描述，是否最小分类（必填，单选）。最小分类的概念是指在运营维度该分类已达到平台所需的最小粒度，没有必要在其下继续细分分类。

对于非最小分类的节点，选中该分类还会有额外的两个页签，第二个页签是在当前分类下新增子分类，第三个页签是当前分类下一级子分类的排序操作。具体的界面下图：

图片 2

分类详情

图片 3

子分类新增

图片 4

子分类排序

具体的页面交互细节就不说了，值得注意的有二：

对于是最小分类的节点，则其没有子分类的新增和排序的页签，而是有额外的页签：分类属性。具体页面如下：

图片 5

分类属性这个页签主要是定义当前分类的商品具有哪些属性。这里有几个概念需要先解释下。

图片 6

图片 7

图片 8

解释了上述概念，编辑和排序的具体细节操作不一一讲了，只讲比较重要的，就是对于最小分类，如何添加和删除属性。

添加属性：分类的属性必须从已维护好的属性库里去选择。具体的操作界面如下，点击添加后弹出查询弹窗，查询到需要的属性后，选择该属性在当前分类下的用途，点击添加，即添加到当前分类。

图片 9

删除属性：若当前分类无商品，则属性可直接删除；若有商品，属性无法真正删除，从某属性组删除后会自动跳入默认的属性分组（每一个分类都有一个默认的属性分组）；

删除属性分组：则需校验当前分组下无属性。

品牌管理的意义在于，维护一个平台共有的品牌库，商品新增和编辑的时候，只能从品牌库勾选已有可用的品牌，从而避免前台一个品牌多个名称，同时在运营过程中也能清晰的按品牌维度操作。

品牌管理主要分为品牌的查询、新增/编辑和删除。具体的新增/编辑页面如下：

图片 10

其他细节不一一赘述，有三点值得注意：

属性管理主要是建立一个属性库，以精确描述商品，为用户提供必要的商品信息。就像我们形容一个人，会用身高、年龄、性别等属性来描述一个人。从前文讲基础类目的时候，聪明的读者应该已经领悟到了每一个基础分类实际上就是一个属性集合（不要告诉我你不是），其实这才是暗合宇宙真理。哲学几大问，第一问就是“What”，要回答what是what，必然是用一个属性集来拆招的。

和品牌库一样，属性库主要也是满足属性的查询、新增/编辑和删除的功能。主要讲下属性的新增/编辑吧。下图就是属性新增/编辑的页面。其中属性的编辑方式是“单选”或者“多选”的时候，下方必须维护可选择的值。

图片 11

其中有一点需特别注意，属性的删除需校验当前属性没有被基础分类关联，若关联则不允许删除。

经过上面的步骤，建好基础分类，建好品牌库和属性库，维护好基础分类的属性，就可以来新增一个商品了。商品管理模块同样离不开商品的查询、新增/编辑、删除以及商品的状态控制。

首先讲下商品的状态控制。一个商品，从商品运营童鞋在后台新增，到上架以便前端用户可见可购买，不仅仅是上架下架这么简单。一个规范的商品管理模块，应该将涉及到商品运营的工作人员的工作流程化。具体来看，需要承担的工作有：商品的新增/编辑/删除（维护商品库），商品的审核（审核内容及售价），商品的上架和下架（日常销售运营），商品的巡查（即通过审核后的抽查）。不同的公司有不同的做法，有的是把职责综合起来，有的是分开来，但不管怎样，上述四个职责，是一定要体现的。下图是商品的管理流程：

图片 12

本来自营的生鲜电商B2C平台没有商家和平台之分，但为了大家更好的理解商品的新增/编辑/删除、审核、上下架、巡查（即上图中的锁定）各种操作，故特意假定自营也是一个特殊的商家，故上述流程引入了商家和平台的概念。具体对应的商品状态有新增、待审核、待上架、审核不通过和已下架5种。

这么多操作中，具体讲下普通商品的新增和系列商品的新增。（建议参考前文给出的商品管理脑图，互相映照）

商品新增的入口在商品查询页面，或者商品详情页。点击新增按钮，出现如下弹窗，其中商品类型分为普通和虚拟，仓库性质为国内仓，直邮仓，保税仓，商品分类为欲新增商品的基础分类。这三个字段决定商品维护的信息不同，以及含该商品的订单处理流程不同，故需要在新增第一步定义。

图片 13

定义好之后，点击确认，则跳转到具体的商品新增页面，如下：

图片 14

要完成商品信息的维护，需将六个页签都维护完毕。其中商品图片主要是上传商品的图片，商品描述是一个富文本输入框，用来输入商品的文描。其余三个页签界面如下（商品页面的操作按钮随着商品的状态变化）：

类目属性页签：主要维护该商品在当前基础分类下的各个属性的值。

图片 15

库存运费页签：主要维护该商品在各地区的所属仓库以及各仓库中的库存控制，还有当前商品适用的运费规则。

图片 16

值得注意的有：

价格设置页签：主要维护该商品在不同平台（APP价格可以设低，以吸引用户转移向移动端），不用会员组别（新用户可低价以吸引用户下单，高等级用户可以享受低价以提升用户忠诚度）之间的售价。

图片 17

一般来说，三个维度的价格已足够。

系列品的概念前文已经讲过，简单举例再说下，就是一件衣服S/M/L不同的尺码，或者不同的颜色。对于这样的商品，有的平台运营后台在后面维护成一个SKU，但带有不同的销售属性，个人认为比较好的做法是，把每个最小物理单位在系统中都维护成一个独立的SKU，只是在前台展示的时候按属性做下聚合，做到同一个页面点击不同属性就切换到不同的商品。如此，价格和库存等所有商品信息，都是每个独立的SKU控制。

具体的系列商品怎么聚合而成，且看下图：

图片 18

上图是平台所有系列商品的查询界面，点击新增，则弹窗如上图右侧，选定系列品的基础类目，品牌以及用哪个系列属性（即前文定义的属性，其用图包含系列）作为聚合维度，点击确认，跳转到系列品的新增页面如下图所示：

图片 19

具体的交互和逻辑就不讲了，只提一个问题给大家，为什么我要限制系列品的类目和品牌？
还有一种商品形态，组合商品（即将两个独立的SKU A和B 打包在一起卖，同时A和B独立也在售卖），不过组合商品现在的应用实际上也没有那么广泛了，就简单讲下吧。
对于组合商品通常有两种实现方式，一实一虚。实的是指组合商品C=A+B是一个独立的SKU，与普通商品一致有必要的商品信息（例如图片和文描），用户下单时系统里生成的订单商品表里直接记录该独立SKU=C的信息，只是在该订单发往WMS履行时，才将A和B而不是C推给WMS，该方式会带来一系列例如库存，销量统计等的不便；故个人认为可行的方式是走虚的路线。即在新增组合商品时，实际只是新增了一条价格设置，当用户在前台搜索到A时，A的详情页会告知A+B的组合优惠价，用户一起将A和B 加入购物车结算时优惠的组合价生效。该种方式组合的商品没有独立的商品信息，但库存管理简单，下单主流程改动较小，对于系统而言，轻而且方便，也实现了以优惠带动目标商品销量的根本目的。
前端分类是指PC或者APP中便于消费者定位某商品而又运营童鞋管理的一种分类，此分类与基础分类最大的不同，在于基础分类是定义一个商品是什么，有什么属性，不同基础分类之间的属性按理是不一样的，一个商品只能属于一个最小基础分类。
前端分类是与消费者联系比较密切的一个分类，与消费者的认知趋同，贴近消费热点，比如Iphone7 128G黑色这款手机，即可能出现在前端“双摄像头手机”分类下，还可能出现在“大屏手机”分类下，或者将各个品牌最新旗舰手机聚合成一个分类，归属于“畅销旗舰“分类下。
前端分类不局限于一颗，有可能PC是一颗，H5和APP是一颗，也有可能APP上不同的频道页的都有独立的分类树。
前端分类树及其分类节点的查改增删就不一一细说了，这里只简单讲一个问题，怎么把商品聚合到某个前端分类节点下？其实这无外乎一个选品的功能，按照基础分类、品牌、和单个SKU三种不同维度筛选出商品，然后聚合即可。
前端分类建好了，商品也关联好了，怎么展示在前台相应的位置？这个简单点的，可以由前端页面接口中写死；更进一步，可以由CMS模块来做配置，指定某页面展示某分类树，这一块，就要在以后的文章中谈到了。
B2C生鲜电商（自营）运营管理平台之商品管理模块至此介绍完了。以上只是笔者从业以来经验的总结，不同的公司有不同的使用场景，其中细节部分大可斟酌，但万变不离其宗，就看大家怎么去架构了。希望上文能给大家带来帮助，坑能少踩就少踩，毕竟出来混，坑自己不要紧，坑了队友那就悲剧了，是吧？