经过前一章节的学习，相信你对购物车的业务和和功能有了一定的了解。其实购物车，很多朋友都多多少少接触过一些，上一章节我们也挖掘了购物车的需求。经过需求的挖掘，相信你应该有一些了解了吧，购物车的功能相对来说比较繁杂，还有一些隐含逻辑，埋得比较深。天猿人工厂君，就和你继续从业务和功能层面去梳理购物车的那些隐含逻辑，至于技术实现，会在设计系列完成之后，的功能实现专辑中体现。
猿设计同样是一个原创系列文章，帮助你从一个只是具备一些技术名词的小白猿人，开始掌握一些行业内通用的设计系统方法，提高你需求挖掘、需求分析、系统分析和设计的能力，完成属于你的能力聚变，更多精彩内容，敬请大家关注公主号猿人工厂，点击猿人养成获取！
提及购物车的那些事情，我们上一章节已经进行过一些需求和功能的挖掘，现在我们通过对功能点的梳理，来挖掘购物车的实体信息已经其背后的隐含逻辑。
从页面展示功能来看，购物车需要展示的展示信息主要有：商品标题、商品图片、价格、数量、规格（颜色、尺码等）、商家（自营或店铺）、库存状态（是否有货）、促销信息等。而这些信息是需要持久化的，那么问题就来了，我们存储数据的时候一条记录的维度是什么？
有很多小伙伴，第一时间就会说肯定是SKU啦，因为SKU的信息很大程度上看上去是唯一的。如果真这样设计，只能讲你过去接触的是假电商，最多只能算是小得不能再小的电商系统了——就一句话，遇到多维度叠加促销你怎么去支持展示。最典型的某SKUA,单买和作为赠品，一条记录怎么办？
带着这些问题，我们先提取下实体，来分析下，购物车应该具备哪些属性。
哈哈，最主要的信息已经放在类图上了，想一想，为什么没有库存？为什么没有促销的明细？为什么没有优惠券？这些变化比较多，持久起来就不合适了。保留关键的信息，到展示前实时获取。
大家都知道，在未登录的状态下，用户依然可以使用购物车，那么购物车就需要把数据存储在用户本地了——一般来说使用cookie来存储。当用户登录时，用户本地的数据就需要和存储在服务端的数据进行合并，这个逻辑比较复杂，我们通过流程图来表示下吧。
由于站点一直在售卖商品，商品的库存以及商品自身的状态都在发生变化。比如说，某个商品下架了，那么进入购物车的时候需要告知用户，我们选择采取默认删除已下架的商品。由于库存也在随时发生变化，需要给用户做无货提示，或者提示用户库存紧张。
那么在购物车中，购物车必然和商品系统/模块，库存系统/模块发生关系了。我们可以通过时序图的方式更直观的来体现这些关系。
提起排序和分类这个问题，可能由的小伙伴，不是很清楚怎么去做了。猿人工厂君可以先提示你一小下，先按商家分组，按照业务规则选择商家顺序（我们来简单点而吧，按sku加入时间倒排吧），商家内部再按促销信息排序。至于怎么来做，天天Map的各种实现讨论得比要不要的，怎么遇到见真章的时候就不行了呢？给你一个数据结构吧，自己看着办Map<Long,List<CartSku>>。
促销信息主要用于商品的展示和选择参考，属于动态获取的信息，值得一提的是赠品类的东西，加入购物车之前就得想好了。画个简单的图表示下就可以了。
关于降价提示这个功能，如果想简单有效一点的话，可以在将商品加入购物车时，保存下商品的当时经过促销优惠的价格。这样一来，只要是有发现促销力度更大的价格，刷新促销价，然后展示价格差额。
但是这样实现由一个弊端——如果用户刷新购物车，那么就看不见了。所以要实现的话，需要两个字段，一个保持初始化时的价格，一个保存最新的价格，只要最新的低于初始化时的价格，就存在优惠提示了。看起来我们需要更新下实体信息了。
选择商品
购物车最基本的操作：勾选商品、删除商品、修改商品数量、清空购物车。删除商品和清空购物车，背后都存在一个隐含逻辑——刷新购物车。修改商品数量这个操作除了需要刷新购物车之外，还要多一个逻辑判断——库存判断。
由的同学可能会说，库存数量可以放在页面上让前端去实现，好多不规范的系统也是这样做的——就问一句话，库存数量能放在页面上被人看见么？所以这个还真得和后端交互，虽然复杂，但是胜在安全。可以化一个简单的流程图。
商品结算
用户在购物车选中商品时，会根据选中实时算出订单金额。同时如果用户选择了不同的优惠，也需要将优惠的金额计算进去。之所以将选择商品的功能放在结算处，是因为选择商品的逻辑和结算相关。而且较为复杂，需要考虑多方面的事情。
以上就是购物车的业务逻辑和概要设计，在接下来的一章中，我们会讲到订单结算的一些事情。可能你会觉得简单了些，或者有不同的设计，欢迎你联系猿人工厂君噢。
