谈到电商，脑海中立刻呈现了双11,618，接着必然会想到促销，各种促销活动琳琅满目，为了自己心爱的宝贝熬夜等待抢购。
电商的促销形式其实都是照搬了线下的促销。我们先来了解下线下促销的方式及种类。
超市最常见的促销--加价购，当你在收银台时，售货员会和你说购物到199了，要不要加5块钱换一包原价10块的纸抽，or你购物满足399了，要不要加15块钱换一瓶原价50的XX花生油。
商场中常见促销--2件9折；4件8折或全场8折；折后满1000再减100。
路边10元店，10元一件区，15元两件区。
线下的优惠促销种类特别多，我们来思考优惠促销的几个要素。
名称、促销时间、用户群体、销售渠道、促销规则（满足促销的条件，及满足促销后享受到的优惠包括减钱，打折，赠品，免运费等）、参加促销的商品。
对于不同种类的优惠促销，其实只有促销规则是不同的。要做到灵活的优惠促销，我们就要把变化的东西和稳定的东西分离。对于一个交易系统，优惠促销分为两大块，优惠促销的创建，及优惠促销的使用。
经过梳理创建过程最多可以分为四步
1.填写基本信息
2.填写规则信息
3.圈定商品范围
4（可选）设置满足优惠后的优惠，比如赠券，赠品，加价购
对于这四部来说我们首先对对第二部的规则进行下总结及抽象，下边这张图列出了我能想到的优惠促销种类
简单对这张图进行下描述，1（满） * 2（件、元） * 7 + 2（直降、套装）=16，当然还可以有送积分，在增加两种。
按照刚才的思路我们来看下创建优惠促销的过程可以通过下面这张图来进行说明
创建的事情抽象之后，在来说使用，对于线下来说，优惠促销的使用很直接，规则加上计算器，无论多么复杂的优惠促销都能通过这两个东西来搞定，前提是人来做。对于交易系统来说想实现灵活的，可扩展的优惠促销就需要对促销本身进行抽象，其实也就是对促销规则的抽象，购物车中需要展示优惠促销相关信息（是否满足活动，优惠了多少钱，不满足的话还差多少满足）为了支持优惠促销的扩展，在我们的交易系统中不能感知是某种促销，系统中不能有任何关于优惠促销类型的特殊处理。这块我们抽象了X、Y、Z、A、B这几个变量分别代表满足条件的金额，优惠金额，叠加次数等。这样在交易系统中我们就不需要关心到具体是什么促销类型，这样我们就可以对优惠促销进行扩展。
刚才说到了购物车中展示的相关信息是谁来计算的呢？这块由我们的规则引擎来进行计算，在购物车中加减商品数量及勾选、取消商品都会调用我们的规则引擎，规则引擎负责根据我们给定的商品及商品上的促销规则，计算出相关展示信息及分摊信息。
这样一来我们把变化的规则在交易系统中进行了抽象，同时把动态计算的部分交给了规则引擎。每增加一种新的促销规则，我们只需要开发相对应的组件及在规则引擎中增加一种规则，而我们的业务系统不需要做任何的改动。
其实单个的优惠促销不是很复杂，复杂的地方在于各个优惠促销之间的叠加，比如系统中有满减，有满折，还有满免运费及直降在这些规则之中需要定义出来每种优惠促销的优先级，及每种优惠促销之间的叠加关系，举例来说明p代表优惠促销
sku1 参加p1及p2
sku2 参加p2及p3
sku3 参加p2及p3
p1和p2两个互动是可以进行叠加的，p2和p3是可以进行叠加的，那么在购物车展示的时候怎么聚合呢？是个问题，相信做过优惠促销的可能更能理解，这个问题怎么能解呢？
以下是我个人的思考，一般来说一个sku能够参加多个活动这个是毋庸置疑的，但同时一个sku只能参加一种优惠促销，基于这点以上这种情形在购物车展示的时候问题就来了sku1怎么展示呢？大家可以想想
以下是我的解决办法，先聚合优惠促销，比如p1和p2先绑定规则，定义好他们之间的与或关系，定义好这个之后这就算做一个优惠
促销，同理其余两个也是一样的，这样算来sku对应的活动应该是这样了
sku1 P11(p1&p2 )
sku2 P22(p2&p3)
sku3 P33(p2&p3)
这样sku1、sku2、sku3就分别对应到了P11、P22、P33上了，这样我们的规则又变得简单了。
下边贴出我们简陋的页面哈哈。
上图列出来的每种优惠促销我们认为是一个业务系统的最小促销规则，我们可以增加促销规则，比如套装，直降，赠送积分。理论上基于这些规则我们能够创建组合出任意多种优惠促销，满足市场多变的营销活动。其实在原来的设计中我们支持任意多种的优惠促销的叠加（规则引擎就比较适合做这个计算），考虑到超出两种的优惠促销组合后很难描述清楚，所以我们在业务层面限制了只能任选两种促销规则进行叠加。其实我们在做设计的时候底层应该尽量灵活，不要限制的太死，在业务层做控制，这样不至于当营销人员或产品在提出要变成三种组合的时候我们很被动。
