前面将活动抽象成了规则检验和一系列的操作，不同的活动的规则有重叠也有不同，如何设计才能保证最好的扩展性。 规则引擎的出现就是制定一套规则检验的模型，下面来看下具体的设计。
主要分为以下三个关键模块
- 规则实体
存储规则属性 - 规则检验器
执行规则检验，检验不通过可以自定义文案，该文案可以展示给用户看 - 执行引擎
串联业务请求和规则检验
-
活动参与条件判断 活动规则这里采用的是单规则检验失败跳出方式，只有一个规则检验不通过，就结束了。
-
红包使用规则判断 红包等一系列优惠载体对于使用也会有一系列的规则检验，同活动不同，所有不可用的原因都需要展示出来。 通过这个规则引擎其实也是支持的
- 规则在DB层的存储尽量按照相同的结构，可以采用列扩展的方式，自己定义一个规则解析器读取对应的值，组装成规则集合
- 跟前端约定格式之后，例如采用[{"code":"StartTime","value":"123445"}]这种JSON串格式，就可以很方便支持规则的扩展， 活动管理相关的代码服务端基本上就保持不变
- 新增规则增加对应RULE实体和Checker的逻辑即可