数据人学习平台上线：
关于作者
@知乎：邹志全
注重提高营销体系效率，
自动化营销与精准运营的长期实践者，
进行有效的编码，
“数据创造者联盟”成员。
01
前言
低代码概念这两年非常火，看似是解决代码开发难题的灵丹妙药，但低代码并不是所有场景都适用，在一些“业务逻辑复杂多变，但单个业务功能点逻辑复杂度不是很高”的场景，低代码平台是提升此类业务系统效率的利器。比如审批流管理、营销活动搭建、常规H5建站工具、注册签到功能等，业内也有不少低代码平台布局。
我们先来了解一下低代码的概念，低代码通常是指一种可视化的开发方式，能够用更少的代码、更快的速度交付应用。把程序员不愿意开发的代码自动化就叫低代码。类似的概念还有“无代码”，也是一种开发方式，通常针对非技术从业人员。不需要写任何代码就可以搭建应用，所以两者的区别主要在于人群的不同，以及对代码的容忍度。以拖拽式H5建站平台为例，拖拽式H5建站平台本质上是无代码的，而基于H5建站DSL或者规则引擎进行编程就是低代码，H5建站平台本身的开发就是纯代码开发。
这些概念没必要区分得那么清楚，人们通常所说的“低代码”，大多是指“无代码”+“低代码”。
本文主要从活动工厂的角度看低代码建设，低代码平台的建设思路是互通的，思路和架构方案大致类似，其他业务场景可以适当微调适配，个人认为大业务领域低代码建设效率最高，适用于所有业务，纯粹的低代码不存在（仅个人观点）
02
收入分析
前面说了低代码平台有多有效，我们再来看看它是如何提高效率的：
2.1 平台定位分析
当我们构建一个系统时，通常涉及四方：
1.该功能的直接用户（用户、销售、运营和第三方系统）；
2.功能运维方（负责功能运营、产品等后端操作）；
3. 功能构建器（研发部）;
4、机器费用等基础资源运维方。
2.2 效益分析
我们的系统成本主要由研发建设成本、功能运维成本、资源成本组成。首先低代码手段可以直接降低功能的开发成本，而且功能优化迭代速度快，所以功能运行成本也间接得到了优化。由于低代码是基于 Faas 思想的资源隔离部署，所以也在一定程度上节省了机器资源。
当节省的开发成本可以抵消新的低代码平台的工作量时，整体效益无疑是积极的。
纯代码、无代码、低代码在开发迭代成本上的差异，以只有一个玩法的活动为例：
03
代码入口点
我们通常的开发流程是业务需求提出后从领域建模开始，然后构建服务，最后发布运行（B、C两端）。我们的低代码流程主要集中在代码建模和服务构建上。各模型的代码建模阶段主要包括职责定义、属性定义、逻辑开发等。服务构建过程主要包括模型的直接串联关系、组合关系、决策逻辑的开发等。
04
低代码组装架构设计思路
对于低代码这部分，我们先从粗粒度去分解，某个领域某个场景下的业务可以分解成若干个功能，功能又由若干个业务能力单元组成，业务能力单元又由若干个原子能力组成。如果要进行低代码设计，最直观的想法就是以拼图或者积木的形式去搭建，然后在过程中填充一些业务逻辑。
所以整体思路就是上面反汇编的逆过程：
以上是经典的 Faas+组装式架构设计方法，不仅可以用于低代码实现（使用低代码手段组装），也可以用于一些复杂的日常业务的架构。我们可以用同样的思路，对零散的部分进行组装式开发（只是纯粹的代码复用思路或者服务复用思路），常见的展示类 Web 服务、密集计算类服务都是用这种处理思路。
4.1 易失性逻辑的处理
对于一些变化很大的业务逻辑，虽然使用低代码时成本较低，但面对巨大的变化还是不太适合，这时候还是需要把这部分从无代码逻辑中抽取出来，在规则引擎或者DSL上构建动态逻辑注入来应对变化。
05
总体逻辑架构
按照上面的思路，经过归纳和抽象之后，整体的逻辑结构差不多是这样的：
蓝色部分为核心低代码能力部分：
网关负责分配我们服务功能点对应的URI；
中间层集成对象建模、服务定义、流程编排、建立复杂领域等核心功能；
最底层是低代码驱动引擎：低代码解析引擎（）、基础功能的注册与发现能力（）、负责服务串行化编排的业务事件总线（）、事件发生时交互维护的总线（data）。感觉有点像CPU+三大总线的结构啊，哈哈哈哈。
深绿色部分为低代码工具库：
第一是集成到当前平台的函数库；
然后是访问外部功能或服务；
最右边是低代码依赖的一些基础能力：上下文存储、自定义存储、表达式引擎、代码生成器等。
如果对常见问题的解决方法感兴趣，可以交流或者单独描述。
5.1 运行视图
06
观看演示
下面我们来看一下如何根据上述整体逻辑架构所呈现的功能，构建一个活动模板并实现一个活动。
6.1 确定玩法
首先，本次试玩活动包含了盲盒抽奖、任务列表、兑换、金豆代币、养成游戏、签到等玩法，整个活动基本就这几个主要的实体，我们会利用这几个模型进行功能设计，确定了模型之后，我们就可以确定玩法之间的关系设计了。
6.2 掉金豆游戏怎么玩
首先金豆本质就是，是一个基础日记账模型，我们直接使用基础功能库中的会计模型作为单位能力，然后不需要做额外的逻辑处理，只需要赋予这个服务一些业务属性（名称等），然后选取我们需要用到的基础功能，就能直接构建出金豆增加、金豆扣除、明细查询、余额查询等能力。
最后，完成API映射，公开“ Bean”功能。
6.3 抵达后如何签到
签到相对麻烦，业务属性比较重，而且没有现成的模型作为输入支撑，这时候就需要我们自己去“组装、拼装”基础功能单元。
1. 确定登录配置的元数据，包括活动ID、时间段限制等。
2. 确定签到实体的元数据，包括用户ID、活动ID、统计时间段、当前计数等。
3.确定我们想要实现的输入能力：签到、补签到、增加签到机会、增加或减少补签到机会
4.确定我们想要实现的输出能力：签到成功、补签成功、连续签到、签到记录
5、根据我们想要实现的功能确定需要用到的基础能力：计数能力、循环计算能力、机会能力、限制能力等等。
6、基础能力的组装和拼接有三种模式，我们可以通过拖拽的方式组合基础函数，关联输入输出，处理各种if-else，也可以直接写代码实现逻辑处理，也可以通过写系统内部可感知的DSL来简化拼接逻辑。
7. 实现输入和输出的 API 映射暴露
至此，签到玩法已经构建完成。
6.4 盲盒怎么玩
盲盒抽奖游戏的组装和拼接都差不多，但是使用的基础功能有所不同。
1. 确定配置元数据，如活动、奖池、奖品及其对应字段
2.确定业务实体的元数据，如用户当前状态、用户中奖记录及其对应的属性
3.确定服务的投入：开盲盒，增加盲盒机会
4.确定服务产出：盲盒奖品清单、盲盒开箱记录
5.确定相应服务逻辑中的基本功能：机会、周期、限制、概率、库存等。
6.按功能逻辑排列基础能力，同样有三种方式，如拖动完成抽奖功能、当前周期、概率-1、限额消费+1、奖池选择、概率选择、计数统计
7.完成相应服务的API对应
6.5 游戏玩法安排
当我们完成了玩法（业务能力单元）的定义之后，我们需要梳理整体的逻辑，把这些相对完整的工具组合成一个真正的活动。
此时我们需要做的是将游戏玩法的各种输入和输出关联起来，并对关联（场景、身份等）做出动态的决策。
例如：
1. 完成任务会增加获得盲盒的几率
2.每连续十天签到一次，汇报周期任务完成情况
3.每日签到增加金豆
4.消耗金豆兑换盲盒机会
5. 完成某些高价值任务可增加获得盲盒的几率
6.签到增加盲盒抽奖几率
该部分的具体设计请参考之前的文章《活动流程安排》。
6.6 前后端协调
总体来说，我们需要这样一个低代码平台的“开发环境”来构建我们的低代码产品，在编辑器里我们可以完成基础业务单元的组装，业务单元之间的拼接等等。
在完成了整体的活动或者说我们的业务功能的搭建之后，接下来的工作就是对我们已经暴露出来的能力进行适配，构建前端的界面，包括B端的操作界面，C端的用户界面。
对于B端操作界面，由于对样式要求不是很高，可以定义一个前端模板，直接渲染低代码过程中生成的元数据和API接口。
对于C端用户界面，可以基于页面功能构建页面功能并通过前端低代码应用进行页面拖拽操作。
07
代码构建后的好处
总体来说，低成本低代码平台的建设给我们带来了很大的收益，整体思路是可行的。整个建设过程带来了很大的业务效益，比如：
1、积累的基础能力不仅可以在低代码平台使用，也可以直接在日常的纯代码开发中使用，也为无代码功能增加了可复用的能力。
2、业务单元能力：由于迭代效率更高，功能丰富度与优化程度更好，往往可以直接复用。
3、业务功能能力在使用过程中不断积累，可直接复用，直接拖拽编排，整体开发成本大幅下降。
4.对于函数来说，迭代更加高效。
总体形势良好，但在低代码平台建设和上线过程中应注意以下几点：
1. 每个职业都有专长，不要贪多，不要什么都做，在一个适合自己的大领域里做专才合理。
2、函数库的积累是一个循序渐进的过程，根据需求逐步沉淀基础功能才是正确的做法。
3、低代码、无代码、纯代码并不互相排斥，界限也比较模糊，只是适合的场景不同，受益的迭代效率和用户群体不同。很多时候一次性单一功能的纯代码开发效率最高（低代码是弯路），无代码可以满足用户群体（适用群体是运营，研发没什么诉求）。功能迭代需求非常快、反向调度需求较多、功能相对相似、开发资源相对稀缺的场景，很适合低代码平台来承接。
4. 不要过度迷恋DSL，用成熟的工具解决问题，现有的脚本语言和数据架构就足以解决问题。
如果想要了解更多数据知识，欢迎阅读由7位各大公司数据产品专家撰写的《大数据实践之路：数据中台+数据分析+产品运用》一书。