作者介绍 @知乎：邹志全 专注营销系统提效， 自动化营销精细运营的长期实践者， 做有效编码， “数据人创作者联盟”成员。 01 前言
先看一下低码的概念，通常是指一种可视化的开发方法，用较少的代码、较快的速度来交付应用程序，将程序员不想开发的代码做到自动化称之为低代码，相似的概念还有“无代码”，也是一种开发方法，通常是面向非技术性员工，不需要写任何一行代码来构建应用程序，所以两者的差异主要是面向人群的不同和对于代码忍受的力度。拿拖拽式H5建站平台来说，拖拽式H5建站平台本质上属于无码、而基于H5建站的DSL或者规则引擎进行编程则属于低码、H5建站平台本身的开发属于纯代码开发。
本文主要站在活动工厂的角度来看低码建设，其中的低码平台的建设思路是互通的，都是大致类似的思想和架构方案，其他业务场景适当微调适配就可以啦，个人认为 在大业务领域下的低码建设是最高效的，适用于所有业务并且纯粹的低码是不存在的（仅仅个人观点）
02
收益分析
2.1平台定位分析
1、功能的直接使用方（用户、销售、运营、三方系统）；
2、功能的运维方（负责功能的后台运营比如运营、产品）；
3、功能的构建方（研发）；
4、机器成本等基础资源运维方。
2.2 收益分析
当节省后的开发成本能盖过新增低码平台的工作量时，整体收益无疑是正向的。
纯代码、无码化、低码化 三种方式的开发迭代成本差异，拿做只有一个玩法的活动来看：
03
代码切入点
03
代码切入点
我们通常的开发流程在业务提需之后，我们首先是领域建模，然后是服务构建，最后发布运行（B、C两端），我们低码的环节是针对代码建模、服务构建两部分进行的，每个模型的代码建模环节主要有职责的定义、属性定义、逻辑开发三部分，服务构建过程主要有模型直接串联关系、组合关系以及关系的决策逻辑的开发。
04
低码-组装式架构设计思路
04
低码-组装式架构设计思路
对于这部分的低码化，首先从粗粒度不断向下拆解，我们一个领域某场景下的业务可以分拆为若干的功能，功能由若干的业务能力单元组成，业务能力单于由若干的原子能力构成，如果想进行低码的设计，最直观的思路就是拼图或者搭积木的形式来构建，然后过程中进行一些业务逻辑的填充。
所以整体的思路就是上述拆解的逆过程：
上述就是一种经典的Faas+组装式架构的设计方法，不仅是低码的落地可以如此使用（利用低码手段进行组装），我们对于日常一些复杂业务的架构也可以是同样的思路，面向散落的零件进行组装式开发（只不过是纯粹的代码复用思路或者服务复用思路而已），常见的展示型web服务、密集计算类服务都是这样的处理思路。
4.1易变逻辑的处理
05
整体逻辑架构
05
整体逻辑架构
蓝色部分为核心的低码能力部分：
网关负责分配我们服务功能点对应的URI；
中间层集成核心的对象建模、服务定义、流程编排、既定复杂领域等核心功能；
其中最底层为低码驱动引擎：低码解析引擎（驱动）、基础函数的注册发现能力（地址）、负责服务串联编排的业务事件总线（控制）、对于事件发生时对于交互维护的总线（数据），感觉有点像CPU + 三大总线结构，哈哈哈哈。
首先是当前平台集成好的函数库；
然后是对于外部函数或者服务的接入；
最右是低码依赖的一些基础能力：上下文存储、自定义存储、表达式引擎、代码生成器等等；
常用问题的解决方案，如果大家兴致比较高的话，可以单独沟通或者单独描述。
5.1运行视图
06
看个demo
06
看个demo
6.1确定玩法
6.2落地金豆玩法
最后完成api的映射实现“金豆”能力暴露即可。
6.3落地签到玩法
1、确定签到配置的元数据，实体中有活动id、各周期限制等等
2、确定签到实体的元数据，实体中有用户ID、活动ID、计数周期、当前计数等等
3、确定我们要实现的输入能力：签到、补签、增加签到机会、增减补签机会
4、确定我们要实现的输出能力：签到成功、补签成功、连续签到、签到记录
5、根据我们要实现的功能确定用到的基础能力：计数、周期计算、机会能力、限制能力等等
6、对于基础能力进行组装拼接，这里可以有3种模式，我们可以通过拖拽的形式将基础函数进行组合进行输入输出的关联、各种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端用户使用界面，可以基于<能力，API>进行页面功能的构建，通过前端的低码应用进行页面的拖拽搭建。
07
代码建设后的收益
07
代码建设后的收益
1、沉淀的基础能力，除低码平台可以使用外，日常纯代码开发也是可以直接用的，也为无码功能增加了一件可复用能力。
2、业务单元能力，由于迭代效率较高，功能丰富度、优化程度要更好，并且很多时候可直接复用。
3、业务功能，能力在使用过程不断沉淀，可以直接复用，由于可以直接拖拽编排，整体的开发成本是直线下降的。
4、对于功能来说，迭代效率更高。
1、术业有专攻，不要贪大求全，在适合且某个特定的大业务领域下建设才是合理的。
2、函数库的积累是一个循序渐进的过程，根据诉求逐步沉淀基础函数才是王道。
3、低码、无码、纯代码并不互斥，界限也相对模糊，他们只是适用于不同场景，受用不同的迭代效率和使用人群，很多时候一次性单功能纯代码开发效率最高（上低码走弯路）、无代码就能满足使用人群（适用人群是运营、研发无诉求），功能性增迭代要求非常快、倒排需求较多、功能相对类似、开发资源相对匮乏的场景就很适合低码平台承接。
4、不要过分迷恋DSL，使用既定的工具来解决问题，现有的脚本语言、数据架构 足够解决问题了。
发表评论 取消回复