作者|泉脉
编辑|橙子君出品|阿里巴巴新零售淘系技术
我通过逛逛的内容营销项目来介绍一下DDD在逛逛内容营销中的应用。
逛逛营销业务背景
在做逛逛内容营销的这半年的里前端做了很多的营销活动，如下图
我们做了各种大大小小的营销活动后，觉得内容营销活动可以剥离出一套通用的解决方案，它们看起来总是大同小异，首先想到的就是搭建。把每一个业务模块开发成组件，然后开放给运营*组合。然而这样有一个弊端就是：每个营销需求来了之后我们都需要评估哪些是已有组件，哪些需要新开发。而且对运营搭建的页面完全失去控制，对性能体验之类的也无从谈起--因为你完全不知道运营会搭建出哪些神奇的布局页面......
业务分析
▐ 从运营的角度看
从业务方的角度思考营销活动，每次的营销都有一定的目的：
-
有的是某类视频的聚合培养用户浏览种草-ex：商品评测类
-
有的是为了引导用户发布模版视频-ex：春节拍同款PK赛-得奖品
-
有的是为了权益刺激，完成任务-ex金晨入驻
▐ 从运营的角度看不同角色的视角
不同角色对营销活动的视角是不一样的
-
业务形态上划分有
-
内容浏览型，--为了给用户种草
-
任务打榜型，--吸引某些流量明星的粉丝
-
权益抽奖型。--采用权益刺激培养用户某些心智
-
UI形态上划分有
-
轮播图+feed流
-
轮播图+任务列表
-
轮播图+权益+feed流
-
从消费者的角度
每个内容营销都可以理解成一种营销玩法，每个玩法都有一个核心组成，用户打开这个活动承载页，就要引导用户去完成这个核心玩法。所以浏览型的活动会突出海景房；任务型的会突出任务；权益类的会突出权益。诸如此类。其他的一些能力比如: banner位，关注卡，话题分类，拉起发布器这些都是非核心元素。他们的存在只是为了辅助装饰整个营销玩法。
-
综上
这样我们就可以把玩法抽象成模版，每个模版对应一个玩法。那么如何划分玩法模版呢？这里就需要用到DDD的思想，领域驱动设计。
从DDD经典架构的六边形架构得到一些启示：
六边形架构又称为端口-适配器，六边形架构将系统分为内部（内部六边形）和外部，内部代表了应用的业务逻辑，外部代表应用的驱动逻辑、基础设施或其他应用。
那么我们的营销活动架构设计可以参照此思想：把一个营销活动划分为核心模块&装饰性模块，核心玩法对应了内部业务逻辑，装饰性模块对应了外部驱动逻辑，他们一起组成了一个营销活动。
建立领域模型
领域驱动设计，旨在建立合适的领域模型。玩法模版就是我们要定义的领域模型
核心模块=>玩法模版=>活动页面
我们把海景房(轮播图)、feed流、任务列表、权益抽奖定义为核心模块，把banner卡片、关注卡片、话题卡片、异步发布等定义为装饰模块。核心模块的排列组合形成核心玩法，核心玩法与N个装饰模块形成一个营销活动，区别在于：核心模块是不可重复的，装饰性模块可以随意重复。也可以理解为：装饰性模块为活动玩法本身的能力的表现，这些模块唤起了这个能力。
整体系统架构图如下：
我们对这个架构有以下约束：
-
核心模块运营同学无法删除or添加，只能隐藏
-
装饰性模块只能在核心模块的楼层上面or下面进行无限制的添加
-
新增一个玩法需要新开发一个页面。一个玩法对应一个唯一的页面地址(分治法)。
至此我们的营销活动整体链路如下：
这套解决方案的核心在于：运营在开始一个营销活动的时候需要明确知道自己的活动目的是什么，然后选择对应的玩法模版(不同的玩法模版解决不同的运营诉求)，运营可以在核心模块的上下界限随意组合装饰模块，形成自己的活动页面。
把每种玩法固化下来，也可以把相关的玩法数据沉淀下来，好的玩法用的人就越来越多。差的玩法业务数据不好，用的人就少了。
总结
有的同学可能会觉得这套解决方案的缺点在于玩法的迭代需要依赖前端和产品去沟通确定，然后再进行组件的组合开发，不如把组件完全开放给运营*组合方便，不过在我看来这并不是问题，作为业务前端我们本来就需要去深入理解每个业务需求，完全的*预示着完全的失控，其次我举例说明一下这套模板化方案的优势：
-
比如我需要在页面的两个元素唤起逛逛内容发布器，这两个模块长的不一样，那我可能需要引入两次发布器的能力，但是在这个模板化的解决方案中，发布器的能力已经集成，只需要把唤起发布器作为一个特殊逇素材坑位处理就行了。
-
在于强控玩法之后我们可以对页面的性能做出很多优化措施既保证了视觉标准规范也保证页面的性能体验。
-
其实运营有时候并不需要那么多的营销玩法页面：参考蚂蚁保险的营销搭建体系的经验