产品管理系统
从事电子商务行业，对电商系统设计的总结，各个模块相互独立，本文讲解商品管理系统的设计。
电商行业商业模式
电商行业现如今有很多成熟的商业模式，大体有一下几种：
B2C：企业与消费者之间的电子商务，类似天猫、京东是属于此类模式，企业在电子商务平台上售卖，消费者进行购买，是最常见的电子商务模式。
B2B：企业与企业之间的电子商务，也可以说是供应方与采购方之间的电子商务，此类模式是解决了上游到中游的采购问题，降低采购成本，类似阿里巴巴的1688。
C2C：消费者与消费者之间的电子商务，此类模式对商家的包容性更大，很多是个人，比如：淘宝、微店都是此类。
O2O：线上到线下再到线上，线上消费，线下服务，线上核销，例如：美团、饿了么。
商品管理系统说明
商品管理系统，是整个电商系统的数据基础，用于记录与商品有关的数据，虽然系统逻辑不复杂，但是由于操作的数据比较多，需要掌控细节，订单，营销，支付，物流等环节都需要从商品中心获取数据。
商品管理系统主要包含以下几个部分：
分类管理：管理商品分类，主要起到对不同商品的归类和；
品牌管理：管理商品品牌，为不同的商品添加品牌；
规格管理：规格也可以叫属性，决定了SKU，SPU，是商品模块重要的部分；
参数管理：参数也叫非关键属性，与规格类似，但是不决定SKU，只起到展示的作用；
商品推荐：商品推荐分常规推荐和个性化推荐；
商品搜索：涉及商品搜索逻辑和之后的展示问题；
商品评论：关键词，敏感词汇的筛选，评论等级等；
商品管理 : 对商品的增删改查以及上下架等其他操作，比较重要。
分类管理
分类也叫做类目，是商品管理系统最重要也是最基础的部分，当我们在设计商品系统的时候应该先设计分类系统。
为什么呢？
分类顾名思义就是将东西进行分门别类，这是衣服，这是裤子，方便我们的辨认。同时商品，规格，参数，品牌都是要挂靠在分类之下的。
前台类目和后台类目
我们平时在设计分类的时候可能只有前台分类，然后分类的标题在前段展示，这种方式其实并不好，原因有以下几点：
不利于营销，如果我们只有一个分类我们给他起名字我们要考虑到后台的操作性，还要兼顾用户的体验是非常困难的。对于用户这个分类可以叫漂亮的衣服，但是对于后台录入来说就会想什么是漂亮额衣服。
不利于管理，你是否有时候想要删掉某一个分类，但是分类下有很多商品？这个时候就很头疼了。
不利于检索，设置丰富的前台类目可以让用户更好的找到分类，可以利用大数据分析用户喜欢搜索什么，然后给分类起名字。
解决方法就是设计两个分类，一个前端分类，一个后端分类。
几个意思呢，后端分类是给我们自己看的，我们要把商品挂靠在后端分类之下，前端分类是给用户看的，用户喜欢什么我们就起什么名字，也就是说给分类起一个昵称，后端分类就好比我们的姓名，前端分类就好比我们额游戏ID。
后端类目要尽量简洁明了让人一看就知道什么意思，同时要易于管理可以加上编号之类的，前台类目根据需求随便其就行了。
那么具体怎么设计呢？
在后台设置两个菜单一个是后台类目，一个是前台类目，后台类目就是我们平时设计的主要包含以下字段：
分类名称：分类的名称，自己起；
前台类目：对应的前台类目是什么；
描述：对分类的描述；
库存：这个分类下还有多少库存；
创建时间，修改时间：什么时候建的，什么时候修改的；
操作：只可以编辑，不可以删除（后台类目不可删除，谨慎）。
前台类目：前台类目和后台类目基本相同，不同之处在于，我们在创建前端分类的时候要注意下，要选择前端分类是挂靠在哪个后端分类之下的，具体挂靠规则我一会再说，不过前端类目一定是要挂靠在后端类目之下的哦，不然就是小黑孩，没有身份。
另外前台类目可以编辑，删除，屏蔽，即便分类下有商品删除也没有关系，因为商品是在后台分类下的，这样的话我们就可以根据营销额需求灵活的变动前端的类目。
情人节到了，那就多弄关于礼物，玫瑰花之类的分类，将其他分类屏蔽掉，冬天的时候可以将关于夏季的服装分类全部屏蔽或者删除。
分类层级
那啥，我说说这个分类层级的问题，根据规模和业务的不同，分类的层级肯定也是不同的。那么这里呢，我是建议统一设置成三级，上衣——羽绒服——男士羽绒服，层级太少，如果商品太多是不易于管理的，层级太深也不行，太深的话就会不利于寻找，找了半天找不到也是问题，所以直接设置成三级类目。
后台具体设计的时候，我建议是后台分类直接设计成三级，然后就不要动了。这样方便管理
挂靠规则
下面说说挂靠规则，首先前台分类一定是要挂靠在后台分类之下的，商品是必须挂靠在后台分类之下的，并且：
商品必须挂靠在最下级分类之下，也就是最小分类，并且只能挂靠一个分类。为什么呢？因为我们创建规格，属性，品牌都必须挂靠在最小分类之下。为啥呢，因为易于管理，如果你不挂靠在最小分类的下面，那你创建这个下级分类的目的是什么，同时挂靠多级会造成理解困难，这个商品到底是什么分类，可能想不明白。
前端分类必须挂靠在后端分类之下，对应关系是比较灵活的，一个前端分类可以对应一个后端分类，同时也可以一对N，N对1，N对N，自由组合，因为商品的挂靠已经有后台分类决定了，前台在后台的挂靠只是因为具体需要灵活运用，对逻辑没有影响。因为不管怎么样，前端显示就会寻找前端分类对应那些后端分类，而这些分类下有哪些商品。
品牌管理
品牌这个东西在一些小的商城里面可能没有，但是为了系统的介绍，我还是得念叨念叨。
设计干货
LOGO：品牌都是有LOGO的，对吧
中文名：品牌的中文名是什么？老张？
英文名：品牌的英文名，zhangser
产地：品牌是来自哪里?日本还是加拿大？
备足：备足说明下
状态：是否启用（启用之后在创建商品的时候才能拉取到）
操作：创建新品牌，编辑，删除，启用/禁用
挂靠规则
品牌的挂靠规则与前台类目的挂靠规则相同，也是挂靠在后台分类之下的，对应关系也是灵活多变的，不再废话，上面说过。
规格管理
规格也叫属性，叫什么无所谓，得知道规格是除了分类之外的另外一个重点，因为规格决定了SKU、SPU、库存、价格，我们在添加商品的时候规格也是最重要的。那么现在来说规格的实际基本有两种形式：一种是单规格单选，另外一种是多规格单选。
单规格单选：一件商品在购买的时候进行单选：红色L，蓝色XL，黑色XXL，这是3个SKU，也就是说有三种价格
多规格单选：一件商品在购买的时候进行多选：颜色（红色，蓝色，黑色）、尺码（L、XL、XXL），一个颜色可以对应三个尺码，33得9，就是9个SKU，也就是说有9种价格。
我建议是选择第二种设计方式，因为可拓展性强，同时也利于前端的展示，下面说下多规格单选的设计规则：
设计干货
规格名称：规格的名称，比如颜色；
所属后台分类：规格是属于哪个后台分类的；
规格值：一个规格名称对应对个规格值，红色，蓝色，黑色；
创建时间，修改时间：什么时候建的，什么时候修改的；
备注：加以备注说明；
操作：修改，删除 （规格下有商品时无法删除），启用/禁用（禁用之后在分类下找不到此规格）。
规格分组
我们在创建规格时，会把规格挂靠在分类下，但是有的时候某一个分类可能会有很多种规则组合，为了便于使用我们可以创建规格组，比如：运动鞋，有的时候可能会有尺码，颜色。
而有的时候可能只有尺码，这样我们在选择规格的时候可能会进行多选，选择我们需要的规格，但是这样也很麻烦，这个时候就引入了规格分组，一个分组下面有多个规格，给分组起名字，这样选择规格的时候直接选择分组就行了，是不是方便很多。
规格在分类中的继承
有些规格是多种分类通用的，我们就可以将这个规格挂靠在夫级分类下面，这样当我们创建商品选择其下级分类的时候自动就会有其上级拥有的分类。也就是说，下级分类继承了上级分类的规格。
这样会让我们方便很多，比如：尺码这个规格衣服类的商品基本都会有，我们把它挂靠在衣服分类之下，这样上衣，裤子，鞋子都会有尺码这个规格，我们选择商品选择鞋子分类时也就可以选择尺码规格了。
参数管理
参数与规格类似，但是不决定SKU的信息，也不决定价格和库存，并且参数名称和参数值可以自由创建，参数只是起到了展示作用，让用户更加了解商品的信息，同样参数也需要挂靠在分类之下。
设计干货
参数名称：参数的名称，比如新旧程度，毛重
参数值：参数的数值，新，旧等
备注：设置备注
商品推荐
商品推荐是商城系统比较常见的功能模块，推荐位置有很多，首页推荐，搜索结果页推荐，购物猜你喜欢。
商品推荐属于营销模块，推荐位置是非常珍贵的，一款软件就那么大，推荐的效果不仅影响用户体验还影响商业盈利，如果推荐的商品用户老是不喜欢，那么用户就会对软件产生厌倦，因为没有我想要的东西，同时也就没有商业盈利了，商品推荐分类常规推荐和个性化推荐两种
常规推荐：手动往推荐位置添加商品，或是根据简单的筛选添加推荐商品，比如销量，浏览量，上传时间等，方式比较简单，对技术要求不高，但是推荐效果不好
个性化推荐：个性化推荐是属于产品智能模块，比如只能排序都属于产品智能。
个性化推荐流程：首先要选择相关数据，就是哪些数据会影响推荐效果，哪些数据可以成为推荐的因素，主要是根据用户的行为数据进行用户行为分析，然后创造用户画像，得出用户画像与不同商品的相关性，设计算法模型，最后进行推荐。
流程就是：数据的采集，数据的分析，用户个性化推荐，不过个性化推荐对用户规模有一定要求，运用大数据是要依赖庞大的数据基础的，这样得出的算法模型才具有实际意义，对于用户量不是太多的商城，基本是采取常规推荐。
商品搜索
用户通过商品搜索可以快速找到自己想要的信息，商品搜索也是流量的入口商品搜索的业务流程是经过4个步骤，其业务流程是这样的，看下面：
输入关键字：首先用户要输入关键字，这个时候后台要对关键字尽心处理，将用户输入的关键字进行拆分处理，比如：春季流行青年运动裤，会被拆分成春季、流行、青年、运动裤，三个关键词，根据用户以往的行为数据找到相关的热点分类。
数据查询：查询出数据库后，系统会从数据库中索引包含关键词的商品，商品搜索时，主要是从商品的标题，分类，品牌，规格等进行关联搜索。
搜索排序：搜索完成后找到了先关的商品，下面就要对这些商品进行排序，排序可以根据商品的相关性，就是用户输入的搜索词与商品标题，分类，品牌的关联度进行排序，关联度越高排序越靠前。还有其他的排序依据：销量，价格，评论数，上架时间，根据这些对商品进行排序。
结果输出：排序完成就要对商品进行前端的展示。
搜索筛选：搜索结果页面一般会支持我们进行商品的筛选，商品筛选可以让用户更快的找到自己想要的商品，筛选的依据一般有分类，品牌，服务标签，价格区间，用户根据关键词搜索到的商品有可能不是同一个类目之下的，经过分类的筛选就可以找到同一类商品。品牌筛选用于找到这个品牌下的商品，服务标签是后台为商品贴的标签，比如，包邮，分期。价格区间是吧价格分为多个区间用户进行筛选。
商品评价
商品评价主要是用户收货后对商品的评价，功能点主要涉及敏感词的处理，评价的形式，以及评价的管理。
敏感词处理：后台要建立敏感词库，对敏感词进行处理，当用户输入敏感词汇时进行特殊处理，比如：星号。
评价的形式：评价形式一般有这几种，文字评价，图文评价，视频评价，星级评价（一到五星），标签评价（后台自定义标签，用户选择，比如：服务周到，物流快）。
评价管理：用户发布评价后后台要进行审核，若审核不通过将删除用户评价，并给出原因说明，商家同时可以进行回复，另外一点就是涉及评价的排序与展示的问题，用户如果长时间没有评价是默认好评还是如何处理，是不是应该将打分高的评价排在前面。
商品管理
商品添加
商品添加是商品管理中最重要的功能，因为商品的信息比较复杂，添加时需要填写的信息比较多，在设计时关键的问题是如何将各部分进行分类，让用户易于理解，便于操作。
添加商品时需要按照顺序填写下面这些信息，商品添加顾名思义，需要添加关于商品的信息，是信息、不是管理，比如：营销，折扣问题在添加商品是不要设置。
分类：对，不是先写标题，而是先选择分类，如果是多级分类必须只能选择最小分类，而且只能选择一个分类，不可多选。
标题：设置商品的标题，主要对字数进行控制。
品牌：显示已选分类下可选品牌，可多选。
规格：选择规格，或者规格组，多个规格和规格值选择完成后要进行编辑对应的SKU信息，有进货价格，销售价格，虚拟价格，库存，SKU编码，保存后生成总库存。
参数：选择参数，或者自己设置参数名称和参数值。
标签：选择标签，比如七天包退，14天包换，正品包邮。
商品图：上传商品图片，多张。
商品详情：文本编辑器。
物流信息等：选择物流模板，或者包邮，选择物流模板用户需要承担运费。
商品修改
商品修改需要将修改后的信息同步到数据库和前端，需要判断什么商品可以修改，什么商品不可以修改，比如用户付费之后的商品是不能同步信息的。
商品删除
删除商品需要在商品下架后删除，商品上架状态不可删除，同时生产订单的商品数据不可删除。
商品上下架
商品上架后再前端展示，下架后再前端不展示。
价格管理
商品上传之后支持对价格的动态管理以便应对业务或者营销的需求。
促销管理
设置商品的促销活动需要调取营销模块的数据，促销活动是在营销模块设置好的，需要同步促销活动数据。
标签管理
对商品额标签进行动态调整，显示哪些或者不显示哪些。
商家管理
如果是多商户商城，还要管理商家的商品，对商家商品进行审核，违规下架等，商家的商品与平台的商品数据相互独立。
库存管理
商品库存变更需要及时同步信息到前端。
其他
商品的限购数量，会员折扣，积分等等，很多模块如果的细致，对商品管理有很大的帮助。
商品的前端展示形式与功能
商品列表页
商品在前端的展示首先会以列表的形式，可能在首页，搜索结果页等其他页面，不管在什么页面其展示形式是固定的，一般是每行一个或者每行两个，展示商品主图，展示信息主要有商品的标题，价格，原价，标签，付款人数，点击进入商品详情页面，商品详情页面是商品信息展示的重要页面，商品的信息基本都在闲情页面展示
商品详情页
商品详情页面是商品信息展示的重要页面，商城的信息流也主要是围绕着商品进行的商品页面一般有如下信息：
商品的多张图片，或者视频介绍，商品的价格区间，商品原价，商品的标题，如果自营显示自营标签，商品的点赞人数，分享按钮，添加购物车按钮，商品发货地址，快递费，销量，优惠券信息，领券按钮，服务信息，规格选择，参数选择，还有评价，详情，商品推荐。
详情页底部一般有店铺入口，客服，收藏按钮，加入购物车和立即购买。
题图来自Unsplash，基于CC0协议
相关阅读
学习要学以致用，于是写了一个粗糙的java图书管理系统，实现了图书的增删改查的基本操作，在写的过程中遇到了很多问题，不过也都通过暴力
功能实现： （1）系统以菜单方式工作 （2）职工信息录入功能（职工信息用文件保存）－－输入 （3）职工信息浏览功能－－输出 （4）职工信息查询功能－－算法 查
在做音视频开发的时候，存在不解码视频帧的前提下需要获取视频宽高、帧率等信息，而H.264中的SPS数据可为我们提供这些相关的信息。在
需求场景: 基于微信平台开发服务号，本地移动端测试时，需要在微信平台注册测试号，然后填写接口配置信息，此信息需要你有自己的服务器
今天分享的是“打卡签到”，简单地说，一些APP上的打卡签到的目的就是用来提升用户粘性。然而其实打卡是一个万能的运营方式，因为你可