前言
建议使用大屏设备(例如pad/pc),可以更好的浏览本篇文章
今天我们开始「商品系统」的篇章。本文分为如下五大模块:
需求分析
架构设计
Spu和Sku的故事
数据模型设计
接口设计
第一篇我们主要看看一个入门的电商平台(B2C)如何去构建自己的基础商品信息,其实这个事情很简单,想想我们的现实生活,商家摆放商品到货架,客户从货架挑选商品,客户把挑选好的商品放入购物车(篮),最后客户去收银台结账。
需求分析
对于一个电商平台来讲,我们怎么理解上面的简单示例呢?接着,我们来拆分上面这个简单的事情:
商家摆放商品到货架,客户从货架挑选商品,客户把挑选好的商品放入购物车(篮),最后客户去收银台结账
商家是谁:电商平台
摆放是什么意思:上架
货架在哪:前台系统(web/app/...)
挑选:浏览前台系统
放入:点击前台系统「加入购物车按钮」
...(暂不多说了)
备注:本篇文章主要来看看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的故事
对我们程序猿来讲「商品系统」刚开始的样子就是如下三点:
创建商品功能:首先我们会有一张商品表,每创建一个商品我们会的到一个goods_id,如果商品存在父子的关系,加一个parent_id的字段就搞定了。
商品列表接口:商品表分页查询商品。
商品详情接口:商品表按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库存表(目前简单设计此表,后期具体业务重构此表)。接着我们列下这些表的明细: