在一些“业务逻辑复杂且非常易变，但单业务功能的逻辑复杂度不是很高”的场景下，低码平台是这类业务系统的提效利器，如审批流管理、营销活动搭建、常规H5建站工具等。本文站在活动工厂的角度，对低码建设进行了分析，一起来看一下吧。

这两年低码的概念始终很火，看上去像是解决代码开发的银弹，但是低码并不是所有的场景都是适用的，在一些“业务逻辑复杂且非常易变，但单业务功能点的逻辑复杂度不是很高”的场景下，低码平台是这类业务系统提效的提效利器，比如说审批流管理、营销活动搭建、常规H5建站工具、报名签到功能等等，业界也有相当多的低码平台布局。

先看一下低码的概念，通常是指一种可视化的开发方法，用较少的代码、较快的速度来交付应用程序，将程序员不想开发的代码做到自动化称之为低代码，相似的概念还有“无代码”，也是一种开发方法，通常是面向非技术性员工，不需要写任何一行代码来构建应用程序，所以两者的差异主要是面向人群的不同和对于代码忍受的力度。拿拖拽式H5建站平台来说，拖拽式H5建站平台本质上属于无码、而基于H5建站的DSL或者规则引擎进行编程则属于低码、H5建站平台本身的开发属于纯代码开发。

这些概念的没必要区分的那么清楚，大家通常说的“低码” 大多是泛指“无码” + “低码”。

本文主要站在活动工厂的角度来看低码建设，其中的低码平台的建设思路是互通的，都是大致类似的思想和架构方案，其他业务场景适当微调适配就可以啦，个人认为在大业务领域下的低码建设是最高效的，适用于所有业务并且纯粹的低码是不存在的（仅仅个人观点）。

一、收益分析

前面提到做低码平台多么多么有效，到底是如何提效的下面来看下：

1. 平台定位分析

我们做一个系统，通常来说参与方有四个：

1. 功能的直接使用方（用户、销售、运营、三方系统）；
2. 功能的运维方（负责功能的后台运营比如运营、产品）；
3. 功能的构建方（研发）；
4. 机器成本等基础资源运维方。

2. 收益分析

我们的系统的成本主要是研发构建成本、功能运维成本、资源成本，首先低码手段能够直接的降低功能的开发成本、功能优化迭代速度快之后功能运营成本也间接得到优化，由于低码是基于Faas思想做的资源隔离部署，一定程度上也节省了机器资源。

当节省后的开发成本能盖过新增低码平台的工作量时，整体收益无疑是正向的。

纯代码、无码化、低码化三种方式的开发迭代成本差异，拿做只有一个玩法的活动来看：

二、代码切入点

我们通常的开发流程在业务提需之后，我们首先是领域建模，然后是服务构建，最后发布运行（B、C两端），我们低码的环节是针对代码建模、服务构建两部分进行的，每个模型的代码建模环节主要有职责的定义、属性定义、逻辑开发三部分，服务构建过程主要有模型直接串联关系、组合关系以及关系的决策逻辑的开发。

三、低码——组装式架构设计思路

对于这部分的低码化，首先从粗粒度不断向下拆解，我们一个领域某场景下的业务可以分拆为若干的功能，功能由若干的业务能力单元组成，业务能力单于由若干的原子能力构成，如果想进行低码的设计，最直观的思路就是拼图或者搭积木的形式来构建，然后过程中进行一些业务逻辑的填充。

所以整体的思路就是上述拆解的逆过程：

上述就是一种经典的Faas+组装式架构的设计方法，不仅是低码的落地可以如此使用（利用低码手段进行组装），我们对于日常一些复杂业务的架构也可以是同样的思路，面向散落的零件进行组装式开发（只不过是纯粹的代码复用思路或者服务复用思路而已），常见的展示型web服务、密集计算类服务都是这样的处理思路。

易变逻辑的处理：

对于一些其中非常易变的业务逻辑，用低码去做虽然成本小了，但是面对巨大的变更依旧是不合适的，这时候这部分仍然需要从无码逻辑中抽离，在规则引擎或者DSL之上建设动态逻辑注入，以此应对变化。

四、整体逻辑架构

根据上述思路，整体进行归纳抽象后整体的逻辑架构差不多长这样：

蓝色部分为核心的低码能力部分：网关负责分配我们服务功能点对应的URI；中间层集成核心的对象建模、服务定义、流程编排、既定复杂领域等核心功能；其中最底层为低码驱动引擎：低码解析引擎（驱动）、基础函数的注册发现能力（地址）、负责服务串联编排的业务事件总线（控制）、对于事件发生时对于交互维护的总线（数据），感觉有点像CPU + 三大总线结构，哈哈哈哈。

墨绿色部分为低码工具库：首先是当前平台集成好的函数库；然后是对于外部函数或者服务的接入；最右是低码依赖的一些基础能力：上下文存储、自定义存储、表达式引擎、代码生成器等等；常用问题的解决方案，如果大家兴致比较高的话，可以单独沟通或者单独描述。

运行视图：

五、看个demo

以上述整体的逻辑架构所呈现的功能来看一下如何搭建一个活动模版，如何落地一个活动。

1. 确定玩法

首先本次demo的活动中有盲盒抽奖、任务列表、兑换、金豆代币、养成小游戏、签到等若干玩法，整个活动中的大实体基本有这么几个，我们就以这几个模型进行功能设计，确定模型之后再确定玩法之间的关联关系设计即可。

2. 落地金豆玩法

首先金豆本质上就是个代币，也就是基础的流水账模型，我们直接使用基础函数库中的账务模型作为单元能力，然后并不需要做额外的逻辑处理，只需要给这个服务赋予一点业务属性（名称等等），然后选择我们用的到的基础函数，便可以直接构建出金豆增加、金豆扣减、明细查询、余额查询等能力。最后完成api的映射实现“金豆”能力暴露即可。

3. 落地签到玩法

签到相对麻烦些，业务属性相对较重，没有现成的模型作为输入支撑，此时我们需要做基础函数单元的“组合拼装”。

1. 确定签到配置的元数据，实体中有活动id、各周期限制等等；
2. 确定签到实体的元数据，实体中有用户ID、活动ID、计数周期、当前计数等等；
3. 确定我们要实现的输入能力：签到、补签、增加签到机会、增减补签机会；
4. 确定我们要实现的输出能力：签到成功、补签成功、连续签到、签到记录；
5. 根据我们要实现的功能确定用到的基础能力：计数、周期计算、机会能力、限制能力等等；
6. 对于基础能力进行组装拼接，这里可以有3种模式，我们可以通过拖拽的形式将基础函数进行组合进行输入输出的关联、各种if-else的处理；我们也可以直接编写代码实现逻辑处理；也可通过编写系统内感知的DSL简化拼接逻辑。
7. 实现输入输出的api映射暴露至此就完成了一个签到玩法的搭建。

4. 落地盲盒玩法

盲盒抽奖的玩法组装拼接也是类似的，只不过用到的基础函数不同。

1. 确定配置的元数据，比如活动、奖池、奖品，及其中的对应字段；
2. 确定业务实体的元数据，比如用户当前状态、用户中奖记录，及其中的对应属性；
3. 确定服务的输入：开盲盒、增加盲盒机会；
4. 确定服务的输出：盲盒奖品列表、开盲盒记录；
5. 确定对应服务逻辑中的基础函数：机会、周期、限制、概率、库存等等；
6. 根据功能逻辑进行基础能力的编排，同样是三种方式，比如拖拽完成抽奖功能，当前周期、机会-1、限制消耗+1、奖池选择、概率选择、计数统计；
7. 完成对应服务的API对应。

5. 玩法间的编排

当我们完成玩法（业务能力单元）的定义之后，我们就需要对于整体逻辑进行编排，把这些相对完整的工具组合成一场真正的活动。此时我们需要做的是对于玩法各种输入输出的关联，并对于关联关系进行动态决策（场景、身份等）。

比如说：

1. 任务完成增加盲盒机会
2. 签到每连续十天上报周期任务完成
3. 每日签到增加金豆
4. 消耗金豆兑换盲盒机会
5. 某些高价值任务完成增加盲盒机会
6. 签到完成增加盲盒机会

这块的具体设计可以参照之前《活动流程编排》一文。

6. 前后端的配合

整体看下来我们需要一个这样的低码平台“开发环境”来构建我们的低码产物，在编辑器里可以完成基础业务单元的组装工作、业务单元之间的拼接工作等等。

完成整体活动或者说我们业务功能的搭建之后，接下来的工作是对于我们暴露出来的能力进行适配搭建前端界面，其中包括B端运营界面、C端用户使用界面。对于B端运营操作界面，由于样式上要求并没有那么高，可以定义一个前端模版对于低码过程中生成的元数据及API接口进行直接渲染。对于C端用户使用界面，可以基于<能力，API>进行页面功能的构建，通过前端的低码应用进行页面的拖拽搭建。

六、代码建设后的收益

整体看下来低成本低码平台建设后，对我们的收益是很大的，整体的思路也是切实可行的，整个建设过程对于业务收益是比较大的，比如：

1. 1. 沉淀的基础能力，除低码平台可以使用外，日常纯代码开发也是可以直接用的，也为无码功能增加了一件可复用能力。
   2. 业务单元能力，由于迭代效率较高，功能丰富度、优化程度要更好，并且很多时候可直接复用。
   3. 业务功能，能力在使用过程不断沉淀，可以直接复用，由于可以直接拖拽编排，整体的开发成本是直线下降的。
   4. 对于功能来说，迭代效率更高。

整体是好的，但是在低码平台的建设启动及过程中需要注意的是：

1）术业有专攻，不要贪大求全，在适合且某个特定的大业务领域下建设才是合理的。

2）函数库的积累是一个循序渐进的过程，根据诉求逐步沉淀基础函数才是王道。

3）低码、无码、纯代码并不互斥，界限也相对模糊，他们只是适用于不同场景，受用不同的迭代效率和使用人群，很多时候一次性单功能纯代码开发效率最高（上低码走弯路）、无代码就能满足使用人群（适用人群是运营、研发无诉求），功能性增迭代要求非常快、倒排需求较多、功能相对类似、开发资源相对匮乏的场景就很适合低码平台承接。

4）不要过分迷恋DSL，使用既定的工具来解决问题，现有的脚本语言、数据架构足够解决问题了。