收藏商品表设计_电商设计手册之基础商品信息

前言

建议使用大屏设备(例如pad/pc)，可以更好的浏览本篇文章

今天我们开始「商品系统」的篇章。本文分为如下五大模块：

• 需求分析

• 架构设计

• Spu和Sku的故事

• 数据模型设计

• 接口设计

第一篇我们主要看看一个入门的电商平台(B2C)如何去构建自己的基础商品信息，其实这个事情很简单，想想我们的现实生活，商家摆放商品到货架，客户从货架挑选商品，客户把挑选好的商品放入购物车(篮)，最后客户去收银台结账。

需求分析

对于一个电商平台来讲，我们怎么理解上面的简单示例呢？接着，我们来拆分上面这个简单的事情：

商家摆放商品到货架，客户从货架挑选商品，客户把挑选好的商品放入购物车(篮)，最后客户去收银台结账

1. 商家是谁：电商平台

2. 摆放是什么意思：上架

3. 货架在哪：前台系统(web/app/...)

4. 挑选：浏览前台系统

5. 放入：点击前台系统「加入购物车按钮」

6. ...(暂不多说了)

备注：本篇文章主要来看看1、2、3、4步该如何去设计。

通过上面的分析我们可以得出下面的信息：

1. 我们需要一个「电商平台」，电商平台里面需要有个商品后台系统。

2. 我们上架什么东西呢？商品！所以商品后台系统需要具备创建和发布商品到前台系统的功能。

3. 我们需要一个前台系统(比如网页)，前台系统具备商品列表和商品详情的页面，可供用户浏览。

4. 前台系统的数据怎么来？所以我们需要一个接口网关(对外统一提供服务能力，企业总线)和商品服务

整理之后得到如下的需求点：

需求点	功能点	项目命名	技术栈
商品后台系统	1.创建商品 2.发布商品到前台系统	Temporal Backend	PHP
前台系统	1.商品列表 2.商品详情	Skr Frontend	Vue
接口网关	企业总线	Skr Gateway	kong
商品服务	1.创建商品接口 2.商品状态变更接口 2.商品列表接口 3. 商品详情接口	Temporal Service	Golang

架构设计

通过上面的需求分析，再加上之前的《电商设计手册之用户体系》中的用户体系和《支付开发，不得不了解的国内、国际第三方支付流程》中的支付服务，我们规划出以下的架构图。

Spu和Sku的故事

对我们程序猿来讲「商品系统」刚开始的样子就是如下三点：

1. 创建商品功能：首先我们会有一张商品表，每创建一个商品我们会的到一个goods_id，如果商品存在父子的关系，加一个parent_id的字段就搞定了。

2. 商品列表接口：商品表分页查询商品。

3. 商品详情接口：商品表按goods_id索引查询商品信息。

很简单是吧，基本一张表就搞定了，看起来也是没什么问题的。但是呢，程序设计的巧妙之处就在于抽象能力，电商行业把goods_id进行了进一步的抽象，产生了Spu和Sku概念，在了解Spu和Sku定义之前，我们还得了解下销售属性的含义，举个例子便于理解：

想想我们的现实生活，假如我们去批发市场上了一批AJ1球鞋，批发商会给我们不同配色、大小的AJ1球鞋。我们在店里销售这些商品时都会询问客户：“您是需要什么颜色和大小的AJ1球鞋呢？”。这里的颜色和大小就是所谓的销售属性，因为不同颜色和大小的AJ1球鞋可能价格不同、库存数量不同，现实生活中是不是如此，不同颜色或大小的AJ1都有差别巨大的价格。

接着，我们来看看Spu和Sku定义：

名称	概念	解释
Spu	standard product unit 标准产品单位	goods_id剥离销售属性的部分，例如：小米8。商品列表我们展示Spu列表。
Sku	stock keeping unit 库存量单位	就是你想买的那个商品真正的编号，这个编号对应的库存就是你想买的那个商品的库存量。Spu+一或多个销售属性对应一个Sku，例如：小米8黑128G，其中黑和128G就是销售属性，小米8就是一个Spu。

搞清楚了么？

数据模型设计

所以最后简单的商品表就拆成了spu表和sku表，接着我们还抽象出来了可复用的销售属性表和销售属性值表。除此之外 我们应该还有品牌表、类别表、简单的sku库存表(目前简单设计此表，后期具体业务重构此表)。接着我们列下这些表的明细：