猿设计17——真电商库存之你所不知道的实体

经过上一章的讨论相信你已经了解库存的一些最基本的业务及电商库存系统的设计理念（不清楚的可以看这里猿设计16——真电商之你不了解的库存）。库存其实是一个复杂的系统，会贯穿整个电商供应链的各个环节。我们今天要做的就是抓住库存系统中的一些实体，针对销售层的库存系统做一个设计，同时预留好调度层、仓库层的设计兼容。接下来猿人工厂君，就带着你去挖掘销售层库存的实体。

猿设计同样是一个原创系列文章，帮助你从一个只是具备一些技术名词的小白猿人，开始掌握一些行业内通用的设计系统方法，提高你需求挖掘、需求分析、系统分析和设计的能力，完成属于你的能力聚变，更多精彩内容，敬请大家关注公主号猿人工厂，点击猿人养成获取！

提及销售层面的库存，我们先回顾一下上一章节的知识，销售库存是由可销售库存、预占库存、活动库存、预售库存组成的，而且库存从狭义上来理解自然是指代商品在仓库中的数量。

嗯，那么问题就来了，既然有仓库，那么这个仓库在哪里呢？没有，那么仓库自然是我们第一个抓取的实体。

看看吧，仓库自然是有ID的，ID之外，编号，名字，配送中心编号，名字，以及库房的类型总得有吧？是真实的仓库呢？还是一个配送中心，或者说是一个自提点呢？修改人，创建时间，修改时间这些属于基本的查水表的属性还是有的吧。

嗯，等等，似乎还遗漏了一些什么东西。是给商家用的吧？仓库的话总有地址吧？嗯。。。确实是这样，不过呢，考虑到如果是B2C的站点，刚才的那个就算是基础表了吧，给商家使用的单独搞一套吧。

既然有了仓库了，可能你会马上联想到，这些仓库都有覆盖范围吧？要不然哪里知道哪些仓库配负责送到哪些区域呢？事实上，就是这么一个思路，不过我们已经在文章开篇讲明了，讨论的是销售层面的事情。那么暂时就不做考虑了。

接下来，我们一起看看库存这个实体。

库存自然反应的是商品数量问题。所以商家编号、商家名称、库房名称、库房ID、配送中心ID、配送中心名称、商品ID、SKUID自然是核心信息了。

那么剩下的数量信息，自然体现的是反应商品的数量属性了。商品+商家+库房+数量其实就是库存的信息了。我们可以看出，现货数量、锁定数量、预占数量、预售数量、都分别代表了库存相关的数量信息。

也许你会比较好奇，为什么心心念念的可销售数量就看不见呢？嘻嘻，因为可销售数量是发生变化的，是一个动态的值，属于一个公式可以计算得出——可销售数量=现货数量-锁定数量-订单预占数量+预售数量。

眼睛比较尖的你也许已经发现了一个很重要的属性——stockState(库存状态)的存在。你一定会好奇，判断一个商品是否可以售卖，有公式动态计算不就好了吗？为什么还需要一个状态呢？

这个问题问得好，因为在实际的业务场景中，可能还面临一些其它的操作，比如库存调整，而且判断商品是否可以售卖使用公式的话，不排除业务逻辑会散发到各个系统。那么在设计的时候，简明扼要的给出一个状态用于判断，是最好不过的事情了，而且也方便紧急情况下的处理——直接将库存状态改为无货，站点上就没有可以售卖的商品了。

以上就是库存实体的一些办法，还没涉及特殊活动（比如秒杀），特殊活动的设计是另外一套思路，需要单独处理，不过你觉得这样的设计是否足够了呢？能满足我们日常的运营需要么？开动你的小脑筋，自己去想一想。下一个章节，猿人工厂君继续带你完成库存系统的设计。

我建了一个技术群，群里有很多高手，加小编微信，备注：学习。带你见识更多的高手，帮你快速成长。