什么是策略发券

几乎每个互联网业务都需要通过优惠券的形式吸引流量。为了实现精细化营销，需要根据用户的特征、用户行为决定如何发券。因此需要在发券系统中引入发券策略。

策略的形式

产品提出的发券需求其一般形式为：

需求项目	说明	内容举例
触发条件	由什么事件触发发券动作	下单成功、接单、支付完成等
命中条件	根据命中条件在多个策略中选择	用户为新用户、下单时间为是上10之前、所在城市为北京
发券条件	在什么情况下发券	用户已有此券、用户有更大额的券时不可发放
发放内容	发什么券	折扣券1张 或者 新用户券2张
通知方法	推送还是短信	发短信内容为：xxx，并且发推送，推送内容为：yyy

触发条件指定了一个策略关心哪些事件。当事件发生时，触发的策略可能不止一个。此时，进一步根据策略命中条件决定采用哪个策略。选定策略之后，策略需要进一步判定用户是否满足发券条件。通常这一步是为了避免重复发券。决定可以发券后，根据发放内容，执行发券。最后通知用户。

系统设计思想

最近对两个重要的编程思想有了体悟，才萌生了对策略发券系统重新设计的想法。这两个思想是：

• 分层
• 模块化

分层决定了一个复杂的程序可以获得概念上的简洁性。模块化决定了逻辑的内聚、单纯、可复用。

很久以前，我想写一个游戏的AI，完全无从着手。因为要关心的方面太多了。细到每一次细微的人物移动，大到战场格局分析。如何将不同层次的逻辑优雅地组织起来？分层。最底层的逻辑只负责每一件小事，如位置移动、物品买卖、攻击、施法等。再上一层，前往某地、战场走位、后勤补给、集中火力攻击某人等。再上一层，打野、gank、抱团、推塔。再上一层，做战略规划，前后期发展方向的决策等。

使用分层思想将整个系统理下来，发现逻辑非常清晰。这也是社会组织的秘密：分层、分级。每一层的工作，就是将下层封装的服务作为基本操作，通过基本操作的组合完成更高一级的操作，向上层提供更抽象的服务。比如：将位置坐标的加减、人物朝向的旋转封装为将前后左右的移动，将前后左右的移动封装为目的地导航，将目的地导航封装为撤退、绕后等操作。

分层是对系统的纵向切分。纵向切分理清业务的抽象层级。横向切分划分了业务的领域。横向切分与纵向切分共同完成了模块化。

系统设计过程

言归正传。我们来对策略发券系统进行领域划分并分层。

策略发券本身是一个独立的领域。不再划分。那么我们来分层。
对于发券策略系统来说，更底层的操作有：券发放、发短信、发推送、触发事件监听、事件参数抽取、命中条件匹配、发券条件检查。

其中， 发券条件匹配粒度太粗了，还可以拆为：用户持券情况获取，持券条件检查
以上操作很明显不是一堆的。我们进行分组：

• 发券：券发放
• 通知：发短信、发推送
• 策略选择：触发事件监听=>事件参数抽取=>命中条件匹配
• 发券条件检查：持券情况获取=>持券条件检查

以上4个部分构成了策略发券系统的4个子领域。其中，发券、通知较为简单，且较为稳定。策略选择、发券条件领域因为运营策略的变化，而灵活改变。下面就策略选择、发券条件两个领域详细说明拆分过程。

策略选择领域的拆分

策略选择过程分为四步：

• 事件监听。这里会经常新增事件
• 事件参数抽取。因事件不同，事件内部所带数据格式不同，因此参数抽取器需要随时扩展。抽取后，参数为统一格式。
• 参数预处理。根据抽取的参数生成一些额外的数据。比如，根据用户id对用户进行分类。根据需求的变化， 这里随时会加入新的预处理器。
• 命中条件匹配。经过参数抽取后，参数格式统一。可以使用固定的机制进行匹配。

以上3步中，前三步都是较为复杂的过程。因此需要进一步拆分为独立的模块，放到独立的包中去。

发券条件领域的拆分

发券条件领域是一个多变的领域。产品为了避免一些边边角角的特殊情况，通常会在发券策略中加一些限制。发券条件限制局限于用户持券的情况。因此，发券领域可以拆分为两个子领域：

• 用户持券情况统计。模块稳定。
• 发券限制条件检查。经常变化。

整体结构

策略发券系统拆分.png

事件处理部分，加入过滤过功能是为了统一过滤掉一些满足某条件的事件。事件生成功能是为了生成虚拟事件。这些虚拟事件领域概念性更强，通常是由原始事件组合、或者加工处理而来。

仔细分析上图中的结构，发券、通知模块是通用的模块。因此，应当作为支撑性的领域。即便是在策略选择领域内，用户分类、条件匹配等机制都能作为通用的模块或者服务而存在。还应该拆分出去。

总结

系统拆分为多少层，划分多少个模块没有标准。易变不易变的部分一定要拆开。易变的部分一定要设计组合扩展的机制，以满足快速变化的需求。

拆分的目的是要控制复杂性。因此，只要拆到每个模块都单纯易理解就可以了。如果模块开始向复杂演化，那么需要再次拆分了。