引言：
当各业务线需求达到一定量级时，且数据不互通，导致同一个功能需求，不断被重复开发，浪费人力资源。鉴于此提出“中台”概念，由熟悉业务的产品及工程师，共同搭建共享服务体系的微服务架构。
将各业务线不同的需求抽象并归类，把共性的服务独立出来。将其功能组合封装成特定功能的共享模块，通过统一接口暴露给前端调用，或基于业务线的特殊要求再次做二次封装。该微服务不仅仅支持功能调用，且作为统一的数据输出及存储的支撑平台。
营销系统作为偏底层数据支撑及管理、营销规则配置的系统，该系统设计规则层及执行层相隔离，支持各业务线灵活配置的营销规则或活动；
规则层是封装完整的可视化操作页面，各业务线可通过接口调用或嵌套浏览器打开，录入规则生成具象活动，由执行层相关模块解析、提取模式，重新组合成代码层的规则并执行结果。
优点：
1、策略规则和执行逻辑解耦方便维护；
2、打通用户、积分、订单、商品系统，可对数据统一存储及管理，输出可视化的数据分析报表；
3、策略规则前端可视化操作，便于运营创建营销工具；
规则层通过固定语法撰写的逻辑，通过解码器解析到服务器，为了防止运营人员误操作，做成可视化的配置项；
梳理各业务线营销活动的历史需求，抽象易变(需求变化频繁)及稳定的需求。将稳定需求拆分成最小颗粒度的元素，将其归类，分成对象、条件、执行，由运营人员自主配置；
在一定的规则变化内，新增对象、条件、执行，可形成新的规则；
缺点：
新规则超出固定语法范围，需考虑如何迭代管理；
基于此，考虑新增数据版本管理功能，针对不同的数据版本分析其依赖关系；
营销工具等同于模板的规则，需嵌套活动模板或券模板使用，无法单独生成活动，该有助于同一规则输出，但也弊于维护两套模板；
历史需求分析
拉新：新客免费领100元优惠券、新客消费立减50元…...
满减：0号柴油满3吨减15元、95号汽油每满3吨减15元……
赠送：消费100元赠10元红包、注册赠10元红包……
从上述例子可见，需求都是与消费、行为、执行、结果组成的，对这些需求进行抽象处理的情况下，会发现类型、对象、条件、执行动作、对象结果、决策因子可涵盖；
如：消费满100元赠10元优惠
类型：赠送类
对象：订单、金额、优惠券，其中订单&金额为决策因子；
条件：满、100元；
执行动作：赠送；
对象结果：给某个消费满100元的用户赠送10元优惠券；
从上述分解可见，某个最小颗粒度的对象，即为元素，元素加逻辑符号等于决策因子，决策因子再加逻辑符号还等于决策因子，可以用嵌套的形式，组合多重关系的决策；满足某个条件执行某个动作，实际为规则内容，通过决策因子及规则内容组合营销工具，但此刻，该规则仅仅是一个抽象层的限制条件，需通过模板规则及创意库素材将其具象化；
其中模板规则包含活动模板及券模板，但在营销系统中，默认优惠券也属于其中一种类型的活动--券活动；
关于规则类型
计算型规则，与“钱”相关，考虑的是如何计算成本、控制优惠力度；
[if !supportLists]l [endif]计算工具类型，如减现，通过类型进行对工具的归类及制定互斥关系；
[if !supportLists]l [endif]计算成本类型，如由x商家的活动，在结算时，计算到底由平台或商家或共同承担该营销工具下所有任务活动及券所产生的成本；
[if !supportLists]l [endif]计算优惠力度，如减x元，实际计算在某个特定条件下所产生的优惠到底是多大，这类规则是暴露给用户，可作为吸引用户参与活动的亮点；
限制型规则，实际为增加规则的限制条件，让活动在可控范围内进行。相对于计算型规则，限制型规则为隐性规则，除特定人群大促活动外，如新客满减，通常不直接暴露给用户；
[if !supportLists]l [endif]数量限制，如限制券模板最多能发放多少金额的优惠券等，该限制核心在于防止在某个时间节点下的高并发导致预算超支；
[if !supportLists]l [endif]参与频次限制，如每满或单次领取，该类限制核心在于控制用户参与的次数；
[if !supportLists]l [endif]用户行为限制，如限制用户触发某些行为后才能生效，该类限制广泛适用于防刷策略，从规则的源头控制，可达到有效的防刷效果；
[if !supportLists]l [endif]用户标签限制，如新客可领取无门槛100元优惠券，该类限制可结合用户及会员体系使用，适用于特定人员的专属活动；包含地域标签、用户价值标签等；
[if !supportLists]l [endif]条件限制，如订单金额满X元，该类作为活动参与门槛，提高活动的参与难度；
[if !supportLists]l [endif]订单类型限制，如次日达订单不参与活动；
[if !supportLists]l [endif]商品类型限制，如虚拟商品（点卡等）不参与活动；
[if !supportLists]l [endif]商品限制，该类限制通常为指定商品或指定商品类目参与活动，如指定商品3件8折；
组合规则可通过计算型+限制型规则组合使用，如新客订单金额满X元减X元，该规则限定用户标签+行为（购买）+工具类型+优惠力度；但并不是每个规则都允许自由组合，单个规则有存在互斥关系。
关于营销工具
营销工具作为本系统的规则层的具象操作之一，每个工具都是由基础属性、工具属性、互斥关系及计算优先级组成。
[if !supportLists]l [endif]基础属性，包含工具名称及工具类型、成本类型；
[if !supportLists]l [endif]工具属性，即是营销工作的核心规则，包括计算型规则及限制型规则；
[if !supportLists]l [endif]互斥关系，是工具与工具之间的互斥关系；
如满减工具设置与满赠工具为互斥关系时，该工具下的活动及券全部互斥，不能同时使用；
但也可运行在模板规则中设置是否互斥，如在模板规则中设置互斥，是子级关系，不会影响到工具的互斥；
[if !supportLists]l [endif]计算优先级，是作为控制多个工具并存的情况下，该优先计算并展示哪个工具；
关于模板规则
工具作为父级，活动模板及券模板作为子级，他们之间存在着继承关系，但作为子级的规则对父级不产生影响。模板规则包含基础属性、周期、具象活动类型；
(未完，待完善)