猿设计5——真电商之颠覆你的类目认知

看过上一章节相信你从感官上对电商的前台系统和后台系统有了一个感性的认知，也学些了UML用例图的基本画法。知道了一些挖掘隐藏需求和分析需求构建系统的办法。但是，如果你真的就这样去构建一个电商系统，那就真的就错了。从今天起，猿人工程君将给大家讲述电商的一些业务知识，从业务的本质上出发，或许会颠覆你对电商固有的认知。

说起类目这个话题，相信大家都会说，这个有什么好聊的，烂大街的东西了，从开源的东西来看，从培训机构的教材来看balabalaba……类目就是一个商品分类嘛，一棵典型的树嘛，一张父子结构的自连接表嘛，有毛好讲的对吧？在这里猿人工厂君真的就笑了，你以为就那么点儿玩意儿的类目撑得起电商了？我们先看看，暂时不说话。

这两张图上的类目是一回事情吗？反正我知道绝大多数人会说是的，毕竟从各种机构的教材和大多数开源产品（真开和假开都算上），猿人工厂君见到的都是没有区别的（发现有区别的告诉我噢，一起玩耍去）。但事实上，这俩就不是一回事情——首页上放着的，叫前台类目，发布商品时用到的叫后台类目。

也许你就要说这不是脱裤子放屁吗，费那个劲干啥玩意儿啊？为啥就不能用一套子东西呢？嘿嘿，甭管你怎么想，反正业务在那儿放着，系统的设计和实现总得从业务层面出发吧？

我们做个简单的试验，你打开主流一点的电商网站首页，点一下图1中展开的二级类目，你都会进入到一个新的页面——频道页面（比如下图的手机频道）。

这是为什么呢？明白告诉你吧，能够称得上主流电商网站的商品都非常多（jd亿级，tb十亿级都挡不挡得住另外讲），商品和类目是有关联的，就不用掰扯了。就说类目，它是一棵树，商品的细分会导致树的层级越来越深。如果买家直接使用后台类目，那么查找商品会变得越来越困难。从运营层面去考虑，如果运营人员在调整类目时，都需要去变更商品的类目，那么工作量绝对是海量的。但是运营这个事情又是长期的，经常随着节日、季节变化而做出相应的调整，如果不解决这个问题，离关门大吉也不远了。

所以从设计上来看，前台类目和后台类目，必须分离了。后台类目相对固定，建立了就不要轻易改动了。用后台类目去应对商家或供应商（自家玩耍的也算），大家都做生意，朝令夕改，会导致都不想和你玩耍的，这样子做也便于建立标准化的商品服务，也利用后续仓储的库存分类分区管理。

前台类目面向用户，方便用户查找商品，方便运营根据销售策略及时调整，甚至可以针对不同的客户端进行不同的设置（PC\M\APP终端大小都不同），前、后台类目之间可以通过建立关联关系，方便以后台类目为基础，快速调整去适应前台的运营策略。

那要解决这个问题，我们还是先逐步分析一下，类目这个实体，都有些什么东西，先从后台类目看起吧。类目有ID吧？有名字吧？有这些就够了吗？我们看看下面这个图，最后得出设计结论。

我们看看这个分析过程，类目有ID和名字对吧，然后我们发现有父子关系对吧？为了方便查询，level作为类目，层级可以记录下，类目是需要排序的吧？那么类目的排序顺序也处理下。至于最后多了6个属性——备注算预留扩展，记录是否有效（是否删除），是否启用，谁最后操作过，什么时候创建的，什么时候修改的算，“简单套路五连击吧”。这些都是需要做数据持久的。

说完了后台类目，我们看看前台类目吧。为了运营方便，一个我们会发现一个比较有意思的事情。鼠标移动到一级类目，会展示二级类目，点击一级二级类目，会跳转到对应的频道页面（只是做得大了都是分站，我们先考虑业务），点击三级类目会出发搜索的功能。其余结构和后台类目类似，我们可以尝试设计下前台类目。为了以示区别，前台类目就叫FtCategory吧。

嗯，好像还忘记了一点噢，前台类目和后台类目之所以要分离开来，是为了运营方便，他们之间自然需要联系了，而要方便关联的话，自然是多对多的关系了。