在游戏产品的生命周期中，游戏运营需要实现各类营销活动，通过 Native 和 H5 页面，投放到游戏端内和各种社交媒体，实现"拉新，促活，回流，付费"等核心目标。然而，一个游戏一生可能需要制作数百甚至上千个营销活动。
本篇内容将聚焦朝夕光年红砖相关架构设计和应用落地经验，以朝夕光年内部场景为例，具体拆解做好质量保障、做好标准化。
内容纲要：
-
流程系统
-
可视化搭建 ------ 领域模型
-
全链路工具
红砖搭建平台就是一个高效且高质量生产活动的平台。它将活动逻辑抽象为一些原子概念，并在此基础上，封装出组件和模板功能。运营和研发人员可以通过可视化拖拽和配置，像用砖块搭建屋子一样去搭建一个活动。除活动创建能力外，红砖同时提供了部署测试、上线发布、数据观测等所有环节，给予游戏运营人员一站式的活动搭建体验。
接下来我们将从流程系统、可视化搭建和全链路工具等三个方向介绍下红砖的核心实现。
流程系统
**
**
红砖将传统的营销活动后端 API 标准化为对流程的调用。流程本身由资格(限制了流程调用的周期频率，如玩家每天只能调用一次)，条件(执行流程需满足的逻辑，如玩家等级需要大于 10 级)和动作（流程执行的动作，如抽奖动作)等原子元素组成。通过核心的规则引擎能力，解读活动配置，调用微服务得到各个服务结果，并计算最终值。所有原子能力都可复用，以实现人力的提效。
比如，一个"玩家每日完成一场排位赛，则可领取 1 个道具"这个业务逻辑可以抽象为：
| 资格 | 条件 | 动作 |
|---|---|---|
| 单角色、每日刷新 | 完成一场排位赛 | 邮件形式发送道具给玩家 |
流程图
可视化搭建 ------ 领域模型
**
**
积木式，所见即所得。运营同学可以通过可视化拖拽和配置，像用砖块搭建屋子一样去搭建一个活动。
而这个模型是采用 DDD 模式，基于 reduck（对 redux 的领域化封装）进行 model 设计。
-
「container Model」：页面容器，全局唯一，维护着整个页面树形结构以及样式数据；
-
「componentModel」：单个组件的数据状态、组件增删改 action，可嵌套子组件；
-
「configModel」：组件动态配置数据，此部分数据含 UI 和 Biz；
-
「canvasModel」：管理编辑时画布的状态，以及一些拖拉拽 action；
其中，通过 container、component 和 config 三个 model，可以完整组装搭建产物 dls（即 uidl），结合渲染器可以直出页面，也可以结合 codeGen 生成代码；
同时红砖建立了跨游戏可复用的模版库，不同游戏之间可以复用活动玩法，为运营提供了现成的优秀案例。
全链路工具
**
**
我们可以在平台上对各类原子数据、操作做单独管理（道具/条件/动作等），通过数据 Mock、时间穿梭等工具模拟用户登录、玩家等级、抽奖结果，我们还在平台上聚合了集成&发布工具，用于进一步提升活动发布效率及质量保证，另外还集成了各类线上运维监控平台，做到对线上数据一目了然。
红砖同时在探索一些新的提效能力，在未来希望使用 AIGC 能力，通过对话获取运营的活动需求，使用更高级的 AI 来自动化生成活动图片素材。