阅读只需要三分钟，转载请注明出处。
api.product.dotnet.sdao
商品库微服务 接口设计说明
-
文档介绍###
商品库微服务是一个是一个用于提供商品管理微服务，
不关注库存。
所有管理功能通过REST api对外接口实现。以下是关于接口
设计思路.
-
设计思路概要描述###
商品库微服务的功能主要包括:
-
分类的CRUD -
容器的CRUD - SPU 及 SKU 的CRUD
- Properties 的CRUD
- Template 属性模板的CRUD
- 以下的均以京东为例：
Option Description url 分类 是一个树状形式的分类展示,携带有scope.scope有web,app,全球购，商品库等等 京东首页 容器 container，显示的空间 This link 京东 的分类为例，二级分类下的列表，有多个列表用于显示的块，一个列表是一个container。 SPU 是售卖的商品，每个商品都有很多的属性，所有的商品都具备有相同的属性集就存在SPU表内 京东商品展示页 SKU 商品.不同商品编号的商品。 Properties 基本属性集 Template 模板属性集. -
-
设计思路详细描述###
- 分类表
字段： { Id:"分类编号" scope："作用域", name："名称", displayName:"显示名称", parentId:"父类编号", order:"排序" ... }eg:
|分类1：scope=商品库分类| +------电脑 +----------整机 +----------笔电 +----------配件 +------手机 +----------功能机 +----------智能机 |分类2：scope=APP_UI_Category| +------首页 +----------推荐 +----------特色 +----------笔电 +----------配件 +------促销 +----------限时特惠 +----------团购 |分类2：scope=Web| +------首页 +----------推荐 +----------热销 +----------时令 +----------数码 +------会员 +----------特惠 +----------团购
>---
>>* **SPU表**
>
> 字段：
> {
> Id:"SpuId"
> name："名称",
> displayName："显示名称",
> brand:"品牌",
> defaultCate_Id:"默认分类Id"
> ...
> }
> 是售卖的商品，每个商品都有很多的属性，所有的商品都具备有相同的属性集就存在SPU表内，比如说Iphone,共同属性有**Id,Name,displayName,brand(品牌),defaultId(默认分类编号**):手机》智能。共有的属性(确定所有商品都会有的属性)就放在SPU表中作为它的字段,不关注库存。
>* 什么是**默认分类**?
>>>比如说：Ipone是属于[3C](https://baike.baidu.com/item/3C%E4%BA%A7%E5%93%81/10865989),手机属于移动电话,相当于类目。
>* 容器相当于分类？
>>>容器也是分类,但是不是此分类非彼分类。这里容器的概念是方便UI展示的。请参考Container表
>
>抛开分类不管，我们只管属性，SPU是所有商品共有的属性：brand,name.....，SKU是一个商品下变化的属性。从程序的角度思考，可以把SPU看成是一个abstract,SKU是它的实现类。SKU{Id,name,displayName,商品编号=Id，外部编号(每一个商品都有一个69码)，Spu_Id}。
>---
>>* **Container表**
>
> {
> Id:'1'//编号。
> categoryId:"1",//特色推荐分类
> categoryName:"特色推荐"
> container_count:"4"//特色推荐下的容器数量
> container_Id:[1,2,3,4]//包含的容器编号。
> jsons:'自定义存储json的内容'
> }
>
>
> 容器表：
> {
> Id:'1'//容器编号
> toples:{title,sub_title,cover,price,link,Id:"可以是文章的，可以是商品的"}//点击点
> categoryId:[1,2,3,4,5] //可以属于多个分类
> }
>
>假如现在要做一个在APP上展示的一个 推荐 产品。如果现在是没有容器这个概念,用来设计的话，需要把 **容器_name**：推荐 作为属性存储。现在我们单独做出一张表来作为容器。容器表有一个**Id**,也有一个**默认显示元素数量**的字段，比如说，我们在一个页面上只展示4个元素块。而不同的列表显示的是不同的。记住，它是一个块的概念。当我们的后台管理人员把**商品入库后**，它手动操作把某一个**入库的商品加入到容器里面**进来。所有这个表也有一个**productId**。每次读取容器的时候就可以查询该容器下的Product。容器它也有一categoryId。
>* 已经存在Category表了,现在容器也有一个categoryId，它是属于Category的吗？
>>>不是,Category是一个Scope下的分类,而我们已经把容器单独抽取出来作为一个表。所以不一样。容器是用来展示的块。比如说一个二级分类（Category表）下有一个推荐分类（Category表）页，推荐的展示页中有一个块属于**”特色推荐“**块,是用于展示的块。而Category表没有展示的概念，是在后台存储的。比如说在上面写的Category分类表，以分类2为例子:**|分类2：scope=APP_UI_Category|**下面有一个首页，首页下边有一个推荐分类。以此为例，假如我们想在推荐分类下展示产品，这个时候我们并不知道该推荐下有哪些产品，APP首页推荐下的产品 与 Web 端 首页 推荐下的产品可能不一样 ，所以我们把Container单独作为一个表。
>
>>>**每个分类(Category表)下有多个容器块或者一个容器块。容器是最小化的，分类（Category是用于划分的）,容器是用来展示的，因为我们在UI下是对显示数量有控制的，容器是没有类目这个结构，它是被分类（Category）包含的。它只对自己容器里边的内容进行界定，比如说items_count(容器数量)，默认放4个，还有items(容器集合),还有自定义存储json的内容（这是一个动态的内容，交给前端处理的，比如说样式，我希望容器的第一条信息加粗显示等等。一个分类包含多个容器，一个容器item下包含若干元素(tople)，这个元素就是一个点击点，用tople表示(点击的意思)，比如说，商品，可以是一个点击点，一篇文章，一个视频都是一个tople,tople由后台自动或者非自动或者人工，把商品的属性添加到这里来，一个tople下有title,sub_title,cover,price,link,Id）**
>
>* 一般浏览京东的时候，浏览一个推荐分类下的”精选3折起“块（容器一），”男子精选“块（容器二），”女子精选“块（容器三），当我点击进去”精选3折起“（容器一）的时候不是有多个商品展示吗？有如下产品（以[adidas](https://shop.m.jd.com/?shopId=58463)为例),会看到多个不同的产品，如下：
>
> {
>
> "男子跑步鞋￥499 ￥899（带封面，点击可跳转）"
>
> "男子训练鞋￥499 ￥799（带封面，点击可跳转）"
>
> "男女经典鞋￥289 ￥869（带封面，点击可跳转）"
>
> ......
>
> }
>
> 回归到问题，一个tople下不是应该是对应多个产品吗？怎么字段是 title,sub_title,cover,price,link,Id ?
>>> 因为这也属于一个商品的共性，容器是用来展示的，tople也是用来展示商品的，因为我们做的是电商平台，所以这里就有展示商品这里针对任何商品，这里展示商品都需要有title,sub_tile,cover（封面，只放一张图）,price,link,Id. 所以这么设计，就是这个道理。这里不会调加所有”3折起的产品“，这个tople只是一个简化的版本。当我们点击了，就会跳转到商品详情页。[男子跑步鞋￥499 ￥899（带封面，点击可跳转）](https://item.m.jd.com/product/10618699195.html),这个时候我们才到商品下去加载商品的东西，什么颜色，尺码等等属性。 **这个Id存放的有可能是文章的Id,skuId等等。**
>
>>>**容器和tople都是用来前端展示的东西**
>---
>>* **SKU表**
>
>是SPU的扩展，SKU可能有N个分类。所以没法写分类Id,但是SPU表下有一个defaultCate_Id(默认分类编号)，所以商品入库的时候用的是SPU表下的defaultCate_Id。
>
> 字段：
> {
> Id:"skuId"
> name："属性名称",
> displayname："",
> 商品编码:"=Id",
> 外部编码:"69码",
> spu_id:""
> ...
> }
>---
>>* **Properties表**
>
> 字段：
> {
> Id:"PropertieId"
> external_Id："外部Id",
> spu_or_sku："type,spu有属性，sku也有属性.",
> name:"属性名",
> value:"属性值",
> unit:"单位"
> ...
> }
>**比如说：**
>
>>| Id | external_Id |spu_or_sku|name|value|unit|
>>| ---| ----------- |----------|----|-----|----|
>>|10 | 1 | spu | cpu型号 | x5 | |
>>|11 | 1 | spu | color | red | |
>>|12 | 1 | spu | weight | 500 | g |
>>|13 | 1 | sku | 内存 | 32 | g |
>>|14 | 1 | sku | color |黑色 | |
>>|15 | 1 | sku | bundle_Items |5,3(都是sku) | |
>
>**这张表以后有可能数据量大的时候需要分库。**
>如果是共有的就写spu，如果是私有的话,就写sku。sku是spu的扩展。spu的属性是重复的属性，sku的是扩展的，所以brand就不需要要了，spu只管非变量的，变量的它不管。
>
> 显示的时候，先查找该商品的spuId以及skuId，然后在进行查询展示。其他的就归前端去展示。
>
>入库的时候，可以选择模板，也可以自己添加。
>
>---
>>* **Template表**
>
>每个人不可能把商品的属性都记得住。所以需要提供一个Template表。模板是由运营人员来写的。手机分类下是一个模板，电脑分类下是一个模板，其它分类下面也是一个模板。所以添加产品的时候有一个分类Id.当我们添加产品的时候，选择了分类后，就会加载默认模板，name就代表属性，以及是否必填项，value就是自己填写的。比如说你卖电脑，就需要把CPU写到规格去。模板的作用就是辅助商品入库的。为了尽量让name不需要自己写而出现这个表的。
>
> 字段：
> {
> Id:"模板编号"
> name："属性名称",
> IsRequired："是否必填",
> categoryId:"分类Id,商品入库的时候需要填写categoryId"
> ...
> }
-
难点区分###
SPU,SKU,Template,Properties之间的关系
例子：你去一个超市，要买一个Iphone,当你跟服务员说：我要买一个Iphone，这个时候
服务员会问你，你要Iphone 6还是 Iphone 6 plus,还是 Iphone 5 还是 Iphone 7等等，会把所有型号问你一遍。
Ipone是代表一个产品的总称，或者可以说是品牌。Iphone 6 plus 可以看做一个商品，进行销售的商品。SPU 就代表Iphone 6，Iphone 6 plus， Iphone 5，Iphone 7。有一个共同的属性:品牌。
品牌是所有商品共有的特性。Properties:添加完一个Iphone 7后，就添加 属于 SPU 的 Properties，这里填写的是
Iphone 7 的共同属性:{weight:xxxg}。而SPU表 填写的是 所有商品（Ipone,电脑，衣服，酒etc.）的共同属性，而color是 Iphone 7这个商品的动态属性:红色，黑色等等。{sku:1,color:红色;sku:1,color:黑色;}所以这个不同的属性是填写属于Iphone 7的 SKU 的SKU 就代表Iphone 6，Iphone 6 plus， Iphone 5，Iphone 7。