猿设计15——真电商之运费设计

经过上一章的讨论相信你对运费模板有了一些了解。为了方便商家设置快速的设置商品运费，我们通过对快递公司的收费标准，和商品发布的综合考虑，抽象出了运费模板的概念。提供给商家使用，从而能够方面的支持运费计算。但是，运费的计算真的只有运费模板一个途径吗？今天猿人工厂君，就继续和你聊聊运费计算的那些事儿。

提及运费，你肯定首先想到了运费模板的使用。在发布每个商品的时候，指定对应的运费模板，然后根据模板的规则进行计算，从而得到在结算页看到的运费。甚至已经在脑海里话出了下面这幅图。

我们先姑且不论运费计算这事儿先由谁来做，就看看这个能否满足具体的需求：满xxx元免邮这种事情经常看到吧？这个可是和订单金额有关了。属于统一的一个规则的设定，而商品上只绑定了一个运费模板，怎么办？

哈哈，事实上，细心的你可能已经发现了我们之前设计时预留的一个属性——templeteType。是的，为了支持多样化的运营方式，我们需要多样性的运费模板。一般来讲，为了支持店铺的统一设置，那么还有一种通常凌驾于商品运费模板之上的运费模板——店铺运费模板。

一般来讲，店铺运费的计算方式主要是固定运费和满xxx元免邮的方式，要么所有订单固定收取多少运费，要么所有商品多少元以下收取多少运费，或者所有商品超过多少之后，收取多少运费。于是运费的计算方式就变成得比较丰富了。主要由以下几种场景：

店铺固定运费：整个店铺设置了统一的运费标准，收取固定费用，不同区域设置的运费标准可以不同，比如成都地区收取固定运费10元。或者成都地区满xxx元免运费，不足xxx元统一收取10元。

单品运费模式：商家将店铺内的每个商品单独设置单独运费，而不设置店铺固定运费，每个商品的运费独立计算。如果一个订单包含店铺下多个不同商品时，平台给予的规则是“运费叠加”或“取最大运费值”两种运费计算方法之一,一般来讲为了防止买家够买商品的运费数目巨大的风险，一般来讲会采用“运费叠加的方式”。

混合模式：如果一个商家设置了店铺模板，又同时为商品指定了单品模板，怎么办呢？这个时候就需要系统设计层面来指定计算规则了。一般来说优先判断店铺运费的条件是否满足，如果商品的金额满足运费上设置，或者店铺的运费金额和商品金额没有关系，那么就直接按照店铺金额来计算，如果不满足的话，那么就需要按照单品运费的方式来计算运费了。

为了更好的描述这个过程，我们可以简单的画一个流程图来体现。

哈哈，这样一来似乎清爽多了。我们先回过头来看下，计算运费是谁的事情呢？之前我们讨论过价格和促销的问题，同样的，运费计算也应该是运费的事情噢。

看起来这样的设计已经很清楚的说明了运费计算的过程了，但实际上运费的计算过程还是比较复杂。商品首先要经过促销计算之后，得到促销之后的金额，才能进行运费计算。而且运费模板的满足条件，还和用户的收货地址有关系。我们画一个更精确的流程图来描述一下吧。

以上就是运费的计算的办法，当然之前的设计中有一些地方并没有满足到位，不过我们业务层面的设计完成之后，在后续的实现中，还会进行详细设计，到时候再给大家讲解。