1、概述

去年写了一个简单的低代码平台，感觉还是挺好的。年底的时候想写个总结，然后发现是自己肤浅了。

原因：其实自己写的是一个工具，且该工具是基于我所在公司的业务做了封装，不具有行业的通用性。

那么现在来讲讲我的理解。

2、低代码平台的理解

一般对此的理解是：让泛IT人员 通过行业化模板、拖放式组件、可视化配置的生成应用的开发平台。

几个关键字：泛IT人员、行业化模板、拖放式组件、可视化配置、生成应用。

泛IT人员：不需要专业的IT人员，只要有相关概念的人员。如：甲方的项目经理，甲方对的办事人员等，了解相关业务的人员。这里强调的是业务，而不是IT知识。
行业化模板：每个低代码平台与平台开发的初衷是紧急结合的。如果是金融领域的，则平台会充满金融色彩；如果是办公领域的，则充满办公色彩。这里强调的是行业的模板，从而做到复用。
拖放式组件：组件分为通用组件、业务组件、页面组件等，也是基于业务导向的，是满足相关业务的基础设施。
可视化配置：通过可视化的方式，提供给相关人员使用，是对外使用的入口方式。这里的可视化方式有很多种，如：表单拖拉方式、页面向导方式等。
生成应用：配置完成后，可以一键部署发布。

总结：本人开发的低代码平台，上次的内容好像都涵盖了，但如果深入思考，则发现未达到某些方便的标准。如：生成应用，一般是生成相关的代码，然后根据服务器信息，自动编译并发布到相关的服务器上，并提供的域名访问。

表单驱动：主要是完成业务数据的收集，以及数据的展示，没有模型的概念。
模型驱动：这是一个平台对的核心竞争力，也是制约一个低代码平台发展的因素。因为所谓模板，其实是一个业务系统，是可以被复用的。如：进入一个平台，它会平台中提供人力资源管理、资产管理等应用，这些管理系统其实就是模型。

可以发散思考下：当一个低代码平台中，存在了一个公司所需要的所有系统模块，且这些模块完成能满足公司的使用需求，则他们只需要在平台中自己配置自己的办公系统。

但这也是最最难的地方，原因则是：业务的变化无穷无尽，平台对的模型如何满足这些变化，或者是未来的变化？

如果小伙伴们知道“业务中台”产生的历史，就应该明白对于“变化的封装”很难很难。

总结：思考下自己的低代码平台，除了满足第一条，部分满足第三条。对于第二条的涉猎几乎没有，只是提供了几个在页面加载、数据操作过程中的事件或者拦截，来满足一些变化的干预，其他的一概没有。

模型驱动，需要从MDD、DDD的设计思想出发，这对于开发人员或者说主控人要求太高。

对于平台二字的理解，如下图：

可以看出，平台基于多租户才能完美的体现复用模型的价值。

总结：自己开发的平台，是基于项目的。是服务公司内容的工具，所以这块的考虑几乎为零。

本人开发的低代码平台是基于项目的，对后台的架构几乎未考虑多组户模式下的要求，所以只能以自己的理解概述。

模型驱动设计
1. 一切皆为模型，将模型与建模拓展到软件开发的所有方面。
2. 形成一个多维建模空间，将工程活动建立在模型的映射和转换之上。
自动化代码生成
1. 低代码开发方式的抽象程度要比传统编程语言高一个level
2. 低代码所生成的代码一般都经过精心维护和反复测试，整体质量强于大部分手写代码
3. 单纯的“少写代码”：只在少数需要的情况下才手写代码，其他时候采用可视化等非代码方式解决。
4. 应用场景的极致抽象并且模型化的过程。
可视化程序设计
1. 全栈、端到端的可视化编程

模型驱动示意图：

技术分支
1. 代码生成
  
  l 国外：OutSystems、APICloud……
  
  l 国内：轻流、H3 BPM ……
  
  l 独立于平台运行，可创建原生App或可在断网情况下运行，运行速度快。
2. 模型翻译
  
  l 国外：Mendix、AgilePoint ……
  
  l 国内：奥哲……
  
  l 主要在公有云环境下运行。安全补丁自动更新，无需重新创建部署。
技术分类
1. 在线 IDE 和编辑器，简化前后端：可视化编辑，易用性好，但牺牲了灵活性。
2. 一站式开发平台：提供了持续集成、部署和运维等功能，包含开发全流程。
3. 深度耕耘某个行业 or 场景，提供模型驱动：CRM、ERP 之类的产品

这个章节我就稍微带下，因为本人开发的平台使用了公司默认的架构，自己没有去过多思考和设计。