电商营销活动系统抽象设计_link66.cn短链接在线生成

营销活动种类及作用

折扣
预售
秒杀
新人价
拼团
满减
买赠
满件打折
优惠券
邀请有礼
签到
红包裂变

在用户的下单路径中，营销系统是如何起作用的，见下面示意图所示：

重构

重构的方向：抽取共性，合并工程。
从业务中来，还得回到业务中去，归纳现有营销业务的一些特点，以及将来的需求趋向。可以将现有营销十几种组件归为三类。

像积分权益、团购、优惠券等后置的营销活动，属于边界清晰、较为独立的服务，暂时不纳入重构的范围。这次讨论的是改价类和组合类这两种前置营销，即在结算前发生的营销活动。

改价类：针对单品进行改价，在购物车中直接显示活动价格。

组合类：针对多个商品进行改价，前置条件是1-n个商品通过数量/价格/sku类型等触发的优惠，优惠形式也有多种: 直减/赠品/N元换购。

虽然分为两类，但这些组件最终的效果都是改变订单中的物品价格，改价类比较直观，而赠品和N元换购同样可以视为将某个商品自动加入到订单中，并对其改价的行为。

除了这点，组件们也有很多相同的属性，如生效时间段、限购、面对的用户群体、生效的sku范围等等。

设计

面向对象的设计：所有依赖关系都终止于抽象类与抽象接口。

OOP的精神无处不可借鉴。在了解到这些共性之后，我们就可以抽象出自己的通用规则模型了，说到模型~~其实像营销体系这类复杂度较高的系统，实践DDD是个不错的选择~

如果营销是类，那么规则就是这个类的一个实例。一条规则会拥有若干字段，按组分类之：

前置条件
用户资格
目标范围
门槛量
限购额度
生效时间
...
优惠参数
优惠方式
优惠内容
...
规格
优先级
类型
...
前置条件决定了如何触发这条规则;
优惠参数决定了触发后如何针对订单改价；
规格决定了这条规则的其他属性：
优先级用来控制规则之间的计算顺序；类型决定了这条规则的业务类型，也就是它代表的是什么组件，用于分组、互斥和触发组件的特有行为。

建表字段自然也就按以上来参考，基本是一一对应，当然最好是预留一些字段。不要高估自己的抽象能力，何况你永远不知道下一个需求有多“惊喜”。必要时也可以建立规则详情表，容纳更多的可能性，总是好的~

建立好规则表，其他相关的业务表也手到擒来了，如商品关联表，优惠记录表等等，这一块的共性很多，设计起来比较自由，就不赘述了，做好和规则记录的关联即可。

在此基础上，就可以开始重构业务模块了，对于一些CURD接口无非就是把库都集中挪到同一个地方了，比较简单。难点在于计价模块，如何通过规则类型来区别化表达这张规则表，从而各种营销玩法都能准确完成价格计算，这里我采用了注解驱动的策略模式。