刚进公司第一周，老大就安排了一个营销平台的需求给我做，活动方式是这样的：用户完成不同梯度的任务数可以获得相应的奖励，在活动期间，必须完成其中一个任务。产品的文档大概也只是多修饰了一下就完事了，产品设计的专业性不提也罢。项目期望是7月1号上线，带我的老大挺照顾我的，报了二周。不过我一周就完成了。目前的代码是简单粗暴的写法，扩展性不太好。在我完成功能的前提下，我进行了代码重构，用活动奖品的规则，我用策略模式+spring抽离出来，活动礼品的领取逻辑用模板模式给抽离出来，代码整洁了很多。

好的产品，需要打磨，此刻我才感觉自己像个匠人，在打磨自己的艺术品。

目前系统臃肿，没有结构化，代码臃肿，不易扩展。将此类营销平台，功能模块抽象成组件，理想的状态是，市场要求上一个活动，只需要后台简单的配置一下就可以了，又或者将相关的组件组合一下就成新的活动了。
这次找工作过程中，阿里系的总监的教会了我去思考领域模型，比如订单系统有领域模型，营销平台当然也有营销的领域模型，就是书上总提到了DDD领域驱动开发，经过一番查询，先人早就总结了一套营销系统体系了，故做下总结，便于后续设计此类系统，可以站在巨人的肩膀上。

营销活动的目的

• 邀新
• 留存
• 促活

营销活动的难点

• 开发的复杂性
  安全性和性能要求高，功能多规则多

• 开发的成本
  普通活动开发也要一周，加上测试，周期长，大型的要2-3周。
  遇到节假日某些爆点营销，时间要求更紧张。

希望解决以下问题：

• 组件化，产品模块解耦
• 可扩展性强，对不同形式的营销形式兼容性高
• 保证营销活动的安全性
• 代码规范，包名统一，异步化，日志规范化统一管理打印。

---

域对象

统一路由组件

请求路由分发，全局异常捕获，日志打印

配置活动解析引擎

不同类型的活动配置组装，关联规则集合和动作集合

规则引擎

规则执行检验器

Rule条件集合

渠道状态规则，活动时间规则，活动状态规则，活动人群规则，参与次数规则等等

Action动作集合

发放红包，记录参与记录，通知用户等等

奖励组件

红包发放

通知组件

PUSH通知，短信提醒等等触达方式

统计组件

数据埋点，活动效果

安全中心

风险控制，黑白名单

后台管理

运营活动设置