本文3300字，预计需要10分钟。
随着数字化、移动化推进软件的需求是显著增加的，而云计算、大数据等基础设施的成熟，人们期望以另一个方式完成软件开发的交付，低代码这个不太新的概念又获得了人们的关注。
市面上有关于低代码有许多争论，但是毋庸置疑的是此领域受关注程度越来越高，根据Gartner报告，市场规模年复合增长率超过20%，厂家、平台很多，侧重场景也有差异如表单类、流程类、设计类等。不过核心诉求无外乎提高效率、降低使用门槛，降低成本。
以下基于通用低代码平台，从组成、核心价值、组件之间的关系、设计/演进原则以及限制简单谈一谈个人的理解。
组成
- 模型
- 布局
布局规范
编辑器
- 编译器
- 流程/逻辑编排
- 任务调度
- 权限管理
- 组件库
布局组件库
业务组件库
- 集成管理
应用集成
API集成
数据集成(输入、处理、输出)
数据管理(导入、导出、批量编辑)
数据质量
核心价值
- 提高效率、降低使用门槛
- 封装知识交付能力
工作原理:封装知识和能力，降低使用门槛，减少沟通协作的环节，这里也请读者思考一个问题：单个客户定制需求真的非得完整走一遍严格的流程吗(需求收集->评审->开发->测试->用户验收->部署)，非得那么多人员参与吗？
组件关系
注:不同场景或者语境下描述会有较大差异，以下为个人理解。
应用的输入应为业务架构活动，此活动原则上和是否使用低代码无关。
业务架构师职责：落地企业战略目标去设计业务解决方案，其解决方案的核心是梳理业务流程、业务数据、明确业务侧的各种协作关系。
输出为：业务流程 业务能力，业务流程=活动集合，活动隐含角色、时机和行为；业务能力可以简单理解为活动执行的能力。而流程的输入或输出会用到数据的定义，因此为业务架构师的输出为:数据定义 业务流程 业务能力。
上图DA、AA、TA 均为平台的组成部分，目标是实现(内置)BA定义的流程和能力。
应用价值通过业务行为达成目标完成价值交付，承担业务实体在平台中成为模型,严格来讲业务模型和数据库中的表以及编程中的class语义上有较大不同。主要差异是业务对象的可能由多个表或者class的组成，其行为更多类似Service或者能力层的范畴。
模型定义: 业务模型定义(可能会对应多个对象，也就是说和对象的对应关系为1对多)主要承载 数据定义。
活动执行: 业务行为，偏向于Service或能力层范畴，有时会通过多个业务行为编排组合之后对外服务。
布局:业务对象展示、数据搜集和行为交互
时机 行为:任务调度
对应用进行抽象，通过平台的元素映射，通过业务组件(对象 布局 对象行为等)完成应用价值交互
平台和应用的关系
- 侧重不用
平台:侧重于通用能力封装和交付。不同平台的定位也会有较大的差异，如基于行业的平台也会内置很多行业内层能力，以及应用之间的协调。管理范畴也不一致。
应用：侧重于业务价值的交付，理论上低代码平台不直接面向用户，而是由应用封装之后以应用的形态交付。
- 生命周期不同
理论上平台的生命周期要远远大于应用的，应用 平台的稳定性理论上也要高于应用的。
- 交付方式不同
理论上应用的交付应该更为轻量，比如可以通过元数据同步、导出/导入应用安装包；导入/导出插件完成交付。
平台一般都需要各种流水线来完成其持续部署。
- 资源竞争
二者存在资源层面存在竞争,组织的目标、氛围、承压能力等会决定二者演进的速度和方向，极端情况应用会"绑架"平台，使其"丧失"通用性。
低代码平台的能力
- 自助能力
降本增效的手段之一是领域封装,减少相关环节，取消不必要的协作、会议。自助完成一些业务功能交付；比如查阅相关知识库或者参考类似的应用配置等。
可调试：一些业务流程经过封装，当需要对功能进行验证时，就需要清楚知道流程输入和输出，以及内部处理逻辑，除维护知识库之外，业务组件的可调试能力(甚至可视化)也是非常重要的。
另外常被忽略的是：由于使用低代码的未必都是专业的研发人员，所以平台要有相对比较强的兜底和监控能力。比如防止误操作，与主动发现使用不合理的地方如多重循环嵌套、SQL不合理等，异常服务的检测与隔离，防止局部使用不当引起大范围故障。
- 知识库
这个能力本来想放在自助能力中，后面想了想还是单独拿了出来。因为知识库维护和使用的未必是同一个角色，知识库包括规范、流程文档、平台知识库，应用知识库，最佳实践等。
知识库需要系统的持续维护，使用者最好可以直接"抄作业"完成相关功能的交付；知识库还需要提供良好的搜索能力，否则很多宝藏只能被尘封。
- 知识封装
将开发、业务专家的能力固化到组件中，方便一线人员使用。
同时将相关作业要制定相关作业标准，做到"填空"式作业，一定要杜绝千人前面。做到有纪律，重细节、够专业。
- 自动化能力
如果面向活动营销类的平台可以实现,从设计稿到页面的输出。
如元数据版本管理，应用的持续部署等能力。
- 复制能力
应用的复制能力：从A环境同步到B环境，需要清楚控制同步的文件，同步的内容，否则功能上线就是灾难。
多环境能力：随着生产和开发环境的迭代，如何能在开发、测试环境快速mock 生产的环境，或者如何把生产的环境脱敏"复制"一个，进行功能验证。
- 扩展能力
低代码本质是通用性非常高的底座 相对完善的插件。应用本身也是以"插件"的形式与平台集成，所以要考虑插件的开发、代码复用、版本管理，持续集成，以及卸载能力。
除了MVP版本有需求免疫的超能力之外，真正交付应用时，总有那么一些能力在规划的范围之外，采用何策略进行兜底，以及兜底的成本都是要进行考虑的议题。
部分业务类型有强事务的要求，在扩展插件场景、尤其是多进程的环境下，需要考虑事务一致性的管理等。
- 私有化部署
相对来说平台可能会用到较多的中间件，甚至云上的很多能力如云函数、高可靠的消息中间件等，那么也要考虑在私有部署时是否有可以替代的中间件。
云环境自动备份、Paas资源监控、水平扩展相对成熟，私有部署时，这些能力一般不如云完善。需要考虑资源的容量规划、监控等。
- 集成能力
三个维度的集成:业务集成、数据集成、api集成。落地时更多的以API或者数据集成的形式，数据集成时需要数据有很好的自描述能力，或者平台可以导出相关数据的定义。API 则要考虑应用之间的认证、鉴权等，以及上下游数据一致性验证等。
除内部接口外也可以接入一些外部服务，如图像识别、资料审核等接口；设置还可以接入一些API的应用集市等。
- 安全、合规能力
安全能力自不必说，平台提供应用的宿主，某种程度上也提供了底层一定安全等级的承诺，部分行业对数据的安全有强制的安全、合规要求就更要充分考虑，内置行业规范。
- 可视化能力
可视化的方面比较多，如流程可视化、配置可视化、开发过程可视化等。
开发过程比较理想的情况是提供一个功能丰富的在线IDE,可以实现代码校验，职能提示，语法高亮，以及相关调试能力等。
配置可视化：就是常说的拖拉拽，配置过程要充分考虑受众，部分平台在配置时仅提供界面操作，但是有的复杂的表单通过鼠标操作就过于反人类的；建议可以将配置导出(生成)文本文件，然后再导入;局部配置时最好也可以提供文本式的模板，文本的操作还是有很大的优势。建议开发、设计者多体验一下复杂场景的配置，不要过于沉迷所谓的拖拉拽。
- 国际化能力
设计/演进原则
- 完善平台vs 交付应用 取决于组织的目标，以及所处的阶段，研发低代码平台时需要考虑二者的平衡。
- 平台和社区之间
现在已经很少有公司可以不依赖社区交付软件，很多开发语言也是社区提供的如java、go等。不论后端还是前端的运行时都需要考虑和社区的关系，主要考虑避免过渡依赖社区，应该通过相关规范将其隔离。同时也要有升级的能力, ，避免"祖传"代码，找不到合适的人维护。
- 社区
平台终极的理想是有一个丰富的社区应用仓库，可以由内、外部伙伴完善平台的业务能力，那就要考虑平台的升级兼容策略，社区培养和治理等工作，以及相关生态建设等。
限制
- 低代码构建本身就是一个大工程
自身构建一个大工程，综上所述除了解决低代码平台自身的开发，还需要有一批业务专家参与共同制定相关的主题领域。
也以考虑直接使用业界低代码平台开发、交付应用。
- 组织和流程
组织包括人员以及人员之间的关系，低代码自身内置了对人员的要求，如平台开发人员，应用开发人员，业务专家等。不同的角色有不同的能力模型，需要考虑市场上是否有匹配的人才，还需要考虑平台的能力要求是否适合员工的成长，否则员工工作能力不能迁移，甚至不满足于能力被平台"绑架"而离开。
以上为个人一点流水账式的认知，如有不当之处，望指正。
注：
以上部分观点参考"说透低代码"
https://time.geekbang.org/column/intro/100108401?tab=catalog
4A截图来自<<业务架构解读与实践>>
