猿设计21——真电商之订单结算

经过前面一段时间的学习，相信你对类目、属性、商品、促销、库存、购物车的业务和设计有了一定的了解。上一章节我们也讨论了结算系统的功能以及业务逻辑。电商的系统最终的目的就是为了向用户售卖商品，当我们具备之前一系列的准备之后，最终于可以去触碰最重要的一个环节了——下单。

相信大家一定经常在电商网站购买东西，也熟悉下单的基本操作，但实际上订单的业务非常复杂，需要好多东西一点一点来贯穿，希望你有点耐心，猿人工厂君，计划用四个章节来和你聊聊下单的那些事儿，今天就先和你聊一聊结算页的那些事情。

上图中的结算页，相信大家都非常的熟悉了。买东西这个事情，最后都是需要结算的。结算页需要考虑哪些事情呢？在这里，工厂君先抛给大家一个问题——订单结算有哪些关键因素？

我们一起来看下吧，网购这个事情，自然是需要送货上门的，所以第一个事情自然就是地址了。所以，对于每一个用户来讲，都需要填写自己的收货地址，以便于送达。由于用户可能需要把把订单送到多个地址，所以在结算页需要提供用户地址选择功能。

如果是新用户怎么办？如果用户的现有地址不支持怎么办？总不可能让用户回到个人中心去维护吧？所以相应的还得提供收货地址的新增和修改功能。

第二个关键点，我们很快也发现了——支付方式。一般来讲，电商网站至少会提供两种支付方式——在线支付与货到付款。两种支付方式的不同，决定了后续不同的订单生产方式。

送货清单中不仅需要列出订单中需要购买哪些商品，每一个商品是多少钱，数目是多少，还需要列出商品的优惠信息，以及商品满足了哪些优惠。猿人工厂君又来卖关子了，这个送货清单有哪些值得注意的地方呢？

第一点，送货清单是按照商家维度分组展示的，除了货品信息还要展示一些商家信息。

第二点，优惠信息必须展示出来，除了告知用户你买了哪些东西，享受了哪些优惠，还要告诉他你再买点儿啥，就能享受到什么服务。一切为了售卖嘛。

第三点，为什么结算页面没有提供促销优惠的选择功能？因为该有的筛选，用户已经在购物车做过筛选了，现在结算就意味着选好了，要结账了。改变决定——那是购物车的事情，先返回购物车吧，一定要有入口噢。

关于配送方式和相应服务，就送货时间而言，对于经常网购的人群很重要，因为大家都不可能一直呆在家里等待收货，下单之后的送货时长也是大家很关心的事情，不过能够提供送货时间服务的网站，都有强大的配送体系。属于另一个层面的问题，先放这里说一嘴以后找合适的时间单独来讲。

发票信息其实也是订单结算的一个重点，因为购买商品的用户不仅仅是个人用户，也有个人用户代表企业进行采购。对于个人用户还好一点，企业用户可是需要发票报账和抵扣税收的，对于他们来说没发票是一定不会买东西的，而且提供发票也是每一个参与商业行为的企业和个人应尽的义务和责任。就我国而言，发票一般分为普票和增票，需要提供的信息不同。

优惠券是用于结算时使用的虽然干的也是促销的事情，但是属于优惠的不同体系了。一般来说优惠券会分为平台券、店铺券、运费券等几大类。用户在结算时自主选择优惠券，结算页也会根据用户不同的选择，显示优惠的金额。

在结算页面价格的组成从逻辑上讲是分开计算的。从金额上讲，需要体现商品原价总价（供货价），商品总促销优惠，运费，优惠券扣减，以及实际支付金额。

从承担计算的职责出发，商品原价总价（供货价），商品总促销优惠属于价格系统/模块的事情。运费怎么来的？还记得话大力气讲过的运费模板吧？运费自然是有运费系统/模块提供了。优惠券的优惠扣减，自然是属于优惠券系统/模块的事情了。

好了，到目前为止，订单结算的功能点我们可以梳理出来了。

嗯，按常规套路，我们是不是应该梳理一下结算页面应该有哪些实体了？不过很不幸的告诉你，结算页面并不需要去梳理有哪些实体——我们考虑实体有一个重要的先决条件——这些信息是否需要持久化。结算页面的信息属于时实计算的瞬时数据，不需要持久化，但是它依赖了很多系统/模块。我们可以简单的梳理下调用关系。

以上就是结算页的业务逻辑和概要设计，在接下来的一章中，我们会讲到订单下单的一些事情。可能你会觉得简单了些，或者有不同的设计，欢迎你联系猿人工厂君噢，至于最后的实现，还有详细设计还有更多的门门道道噢，设计系列完成之后，就是实现了。