分布式电商营销系统的实践之路：抽象规则 / 开普饭

去年供职于一家电商公司，被分配到做商城营销体系的开发设计。本文章记录了我这个小菜鸟在营销设计中遇到的坑坑洼洼，以及在重构中的思路。

首先我们列一列营销组件有哪些。

其次是要知道营销在正向流程，即用户的下单路径中营销系统是如何起作用的，当然这只是简单的示意图，实际业务中要复杂许多。

在这种情况下我选择了一种“理所应当的设计”，即一种组件对应一个微服务。当然LZ不是说这种设计很糟糕，在营销需求不多的情况下这种方式能最快出成果。
其实在营销组件很多的情况下组件、服务一对一的设计仍有优点，因为符合开闭原则，需求变更再频繁，也只需对单个组件进行更改，不影响其他组件的正常工作。

实际上在下游与营销组件之间我会加一层聚合服务，用来收缩营销的边界，统一提供如计价、优惠显示等能力，避免给系统加入过多的耦合关系。

这种线性的服务设计能在迭代初期解决大部分问题，但暴露出来的问题也是显而易见的：

在接受线性设计所带来的弊端后，我着手开始重构工作。这是个困难的工程，淘宝花了十年，经历6次重构，才实现了不上线就可以加组件，不得不说还是NB。

重构的方向：：抽取共性，合并工程，组件不决定服务。

从业务中来，还得回到业务中去，和PM零零散散地归纳了现有营销业务的一些特点，以及将来的需求趋向。可以将现有营销十几种组件归为三类。

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

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

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

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

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

在新的设计中，引入规则的概念。如果营销是类，那么规则就是这个类的一个实例。一条规则会拥有若干字段，按组分类之：

前置条件决定了如何触发这条规则;
优惠参数决定了触发后如何针对订单改价；
规格决定了这条规则的其他属性：
优先级用来控制规则之间的计算顺序；类型决定了这条规则的业务类型，也就是它代表的是什么组件，用于分组、互斥和触发组件的特有行为。

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

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

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

排版不是很好，慢慢进步，peace~

分布式电商营销系统的实践之路：抽象规则