营销平台业务场景化支撑

一、平台业务发展

营销平台发展至今，目前支持的业务已达40+，从最早的聚划算，到后来接入淘抢购，outlets（以前叫淘清仓）组成的营销矩阵，再到2017年来陆陆续续接入了30多个业务，覆盖了自营营销，会员线，品牌营销，新零售等多条业务线，业务成果有目可睹。

但是一个强大的平台并不是一蹴而就的，平台在产品和系统上也经过了漫长的磨练，才能达成现在这种效果，能在1~2周内完成一个新业务接入，部分业务可在1~2天内交付业务进行试用，而产品和开发人员并没有太大的变动。

总结起来，发展历程可以大概划分为三个主要阶段：

• 2010~2015年，聚划算，单站的团购营销系统
• 2015~2016年，营销矩阵，接入了抢购和outlets，这个时候平台能力初现雏形，平台化能力并不完善
• 2017年~至今，营销平台，这段时间内各业务系统完成了平台化改造，数据权限隔离，并将业务接入产品化，极大节约了开发效率，加快了业务的支撑速度

二、现状及问题

但是随着业务的指数式爆炸增长，带给平台的压力不只是业务接入的支撑上了，因为在业务接入产品化改造完后，业务的支撑速度很快。但是由于各系统的功能是全面铺开给各业务使用的，系统能力也耦合在一起，这对于很多新小业务来说，是个很沉重的负担，痛点集中在如下几个方面

业务隔离：

对于所有业务呈现同样的功能，对于简单业务来说功能多且杂；一个功能上线影响全部业务，很多业务同学会经常来问这些功能是干嘛的，答疑成本很高，给业务同学带来的困扰也很大

接入成本：

由于接入业务的时候，各个需求开发的能力都能沉淀下来，但是最终形成的结果是平台功能及规则太多，活动配置项近200项，新业务快速试错成本太高，每一项的解释成本很高，建一个活动花费时间很长

能力复用

上一点也说到了，业务需求可以让系统能力沉淀更多，但是沉淀的能力多的情况下会失控；而且同一个能力想复用到不同的业务线上，必定存在着差异性的规则配置，这份规则配置如何管理成了一个很大的问题，很可能会存到一个开发的临时存储，比如diamond，switch，甚至代码注释里，时间一长，职位一变动谁也不知道了当年怎么回事了。

但是如果想把这个配置项通过产品形式表达给业务，又担心开发成本提升和增加业务的负担。

能力表达

• 系统黑盒执行，逻辑复杂导致系统运行与业务诉求不一致
• 系统能力无法表达，需要翻代码或SOP文档支撑

三、怎么解决

平台业务的分析

分析一下现在的现状，摆在我们面前需要解决的最大的问题是，如何实现同一组产品体系，向业务方场景化表达

• 第一是面对不同的业务需求，业务方只需要关心他们相关配置项
• 第二大层面上的能力组合按照业务需求自由组合

最终达到如下图的效果：

业务模型的抽象和拆解

想要做到能力的组合，那么我们首先要做的能力的拆分解耦以及能力的通用化表达

按照目前平台支撑的业务，我们可以分两个维度来解读

垂直维度

这里的垂直维度我们定义为业务维度，比如聚划算，淘抢购，淘宝直播等等，万幸的是这些业务之间并没有太多的耦合；

垂直维度对应我们系统里面的领域模型就是站点对象；

横向维度：

横向维度的分层就稍微复杂点，我们简单的分为三层：

• 能力域：对于营销平台的最粗粒度划分，基于业务产品来划分，大概划分为店铺招商域，收费域，货品招商域，素材招商域，门店招商域等等，各大能力之间也尽量保持独立。
• 能力：能力是最基本的一个动作，比如货品招商域里，打标，写UMP优惠，触发营销工具生效都算是一种能力；能力之间大部分情况也可以独立存在，比如可以只打标，不写优惠，也可以只写优惠不打标，也可以同时进行。能力分为两类，一种是面向业务同学（非技术人员）的业务能力，一种是面向执行系统的系统能力，后面再讲能力执行的时候会详细讲这个点；
• 能力扩展点：扩展点是对能力的扩展属性，比如拿商品域的打标能力来说，要不要打标是能力维度，打什么标就是能力的扩展点了。

业务分析

下图是比较典型的几条业务线所使用的能力，其实也能看到不同的业务对能力的诉求基本是随机组合的。

业务组装

有了业务模型的抽象定义（横向和纵向），我们可以对这些解耦能模型进行组装（主要是横向的能力组装）

主要分这几部分

• 能力的定义：这里我们主要说的业务能力的定义
• 能力的组织：以产品的形式提供给业务同学进行能力的组织，比如活动创建和管理
• 能力的执行：对于业务人员和系统来言，他们所需要的能力描述就不一定是一一对应的，比如运营同学在活动组织的时候勾选了上主团露出，其实对于系统来说有两个能力，一个是露出费用的收取，一个商品在投放端的露出。所以先需要将业务组织的能力诉求，转换成系统可理解的系统能力诉求，然后各执行系统在执行流程的上下文中，拉取数据，渲染执行逻辑；

大概的系统架构示意图如下

四、技术实现方案

逻辑实现

上一小节我们有了大概的想法，这个部分我们来抠细节

其实对于每个业务能力点来说，其实对于系统来说就是一份数据，只不过这份数据的定义和来源不同，如果这个点是业务想要关系并且想控制的，那么就开放配置给业务同学来配置，如果不想关心甚至不想看到，那么就在业务接入的时候按照业务特性来配置掉，默认隐藏掉就好了，在日常使用中，不需要暴露给业务方，技术同学关心下就好了。

这么一来，我们可以给每个规则配置点定义几个关键的属性

• 唯一标识key
• 描述
• 是否可见
• 是否有默认值
• 是否可允许业务修改

结合这个逻辑，再结合上一张图，我们可以细化下逻辑，如下图所示

技术实现

要涉及到技术细节了话，首先我们得分析下我们的营销组织的关键核心数据模型，如下图所示：在活动组织招商准备的时候，招商活动其实一个核心的数据模型，因为对于业务同学和商家来说，他们面对的最直接的数据就是活动，业务创建奔着一个营销目的，创建一个营销活动，以活动入口为通道和商家达成合作；

这么看来，那么以活动为载体承载营销的相关的规则最合适不过了，实际上各业务执行系统来说，也是直接依赖活动数据作为执行的判断依据。

所以说如果想达到能力的场景化，如果想简单实现的话，就是把活动表达场景化。

数据存储和业务输入的场景化

如下图是整个场景化的驱动核心逻辑，themis_element是基本的业务元素metadata，业务需求通过输入到themis_template中，影响到该模板下所有活动的元素的显示隐藏，默认值和是否可修改。

在这里得益于@月飞 团队的前端组件化框架nrails，我们设计一套通用化的前后端对接机制，由后台逻辑输出hide,readonly,defaultValue来控制页面view层的场景化。

系统执行的场景化

上一步中说的场景化下创建的活动，活动本身就一份规则执行数据，我们只要把活动上的业务数据转义成系统的执行数据分发到各业务执行系统，就可以实现商品/素材在不同的活动下不同的表现形式，活动本身带有场景属性，那就意味着实现了各业务子系统的场景化了。

然后营销流程的支撑，是由各系统执行支撑，系统完成了场景化，上层表现也就可以做到核心逻辑的场景化了。

中间的流程转换层也扮演了一个非常重要的角色，一个是业务诉求到系统诉求的转换，一个是解决了业务层适配不同系统能力实现的适配；比如商品流程系统cargo有一套能力的扫描注册机制，那么转换层可以按照cargo的规范来适配进行数据转换；如果商家报名流程的话，同理也可以自定义适配；如果以后各系统执行层统一按照TMF的标准来实现了，那么只要实现业务能力对TMF的能力表达进行适配就ok了。

五、思考和总结

其实做业务支撑，像很多后台系统一样，不会面临像面向C端的高并发之类的技术挑战，我们面临的挑战大部分是复杂业务逻辑的处理，如果只是简单实现了业务需求，是远远体现不了我们的价值的。如何实现业务系统的高可用，高扩展性才是我们最大的挑战。

阿里是一家商业公司，我们的工作都是奔着商业目的去的，只不过是间接或者直接的关系了；业务支撑的目标是提效，赋能，通过为公司节省运营成本，提高资产的复用率，来实现自身的业务价值。

而平台和业务之间的关系也是相辅相成，平台赋能业务，业务成就平台。希望我们以后能做得更好

这一套体系其实比较庞大复杂，需要很强的系统架构领域建模的理论支撑进行梳理总结，非一人之力所能及，在这里也感谢枯木，良湛的意见，感谢产品，开发，和测试团队小伙伴群策群力，结合业务系统实际探讨业务架构之路，也再次感谢月飞，落更团队给予的nrails前端组件支。

和TMF的区别（更新）

文章发布后，有部分同学私下和我交流中，大家看到业务能力的表达以及域模型定义管理，就会想起tmf2.0；
其实最简单的区分方式就是，这套场景化面向的使用者是运营业务同学，tmf的业务方仍然是各上层系统，场景化解决的是如何以场景化的方式帮助运营组合各底层营销工具的能力，以最小成本服务运营，赋能业务。TMF和星环一套很棒的思路和产品，后续我们在底层系统的改造中，也会思考如何借助集团的这些能力，帮我们把底层系统建设得更好。

六、展望

目前只是完成了第一步的快速落地，借助本次的活动的场景化改造，提升了平台的业务支撑能力；但这还远远不够，我们能力的产品化表达还没完成，由于平台支撑了如此多的业务，这个也是可以利用起来的有生力量，业务之间的隔离让我们的支撑能力更强，但同时业务之间的联动协同对于商家和业务同学来说都是可以深挖的一笔财富。

最后：平台业务文档，欢迎业务合作和技术交流：https://lark.alipay.com/marketplatform/overview