软件在我们的生活中发挥着重要作用。无论是线上活动还是交通工具，整个世界都是由软件驱动的。Gartner 曾说过，一个公司如果想在竞争中胜出，就必须制定软件战略。公司（或少数非营利组织）必须进行改革，参与到软件驱动中来，同时，也要认识到参与其中必然会面临下列三个挑战：
第一、软件工程师稀缺的情况仍在持续且有加剧趋势。
第二、软件开发很复杂，需要软件工程师和相关领域专家的共同努力。从 DDD 和 BizDevOps 的日益普及来看，企业已经意识到了这个挑战。
第三、整个过程不会随着软件开发的完成而停止。公司不是在真空中生存，要与客户、供应商、政府和竞争对手打交道。因此，公司必须不断地更新软件，来满足各方的愿望和要求。
低代码平台，这个由 Forrester 在 2014 年首次提出的概念，可能应对上述挑战的解决方案之一。低代码强调平台能够让用户以少量的编码开发软件系统，通过引入更高层次的抽象，如特定领域的模型，来吸引公民开发者以及没有受过具体的软件开发培训的专业人士的使用。我们当前讨论的热点问题之一是，低代码平台是否是一种新事物，是模型驱动开发的另一种叫法吗？还是模型驱动和其他技术的混合？是否代表了新事物？我个人认为，虽然从技术角度来说，低代码平台没有提供新事物，但低代码平台的目标和重点与普通的模型驱动不同。
从低代码平台的关注点来看，它似乎正在解决上述前两个挑战。让公民开发者参与到软件开发过程中，不仅可以减少对资深软件开发者的需求，还自动将企业引入软件开发领域。但我们的目标还远远没有实现。低代码平台必须满足特定期望才能成功。而这些期望为设计低代码平台（LCP）的软件架构师带来了新的挑战。
首先，LCP 必须支持现代的、基于云的应用程序的开发。一个成功的软件不仅可以让用户在公司电脑上访问，也可以实现在其他各种设备上的访问。其次，我们希望这些应用程序不仅可以供用户访问，还能够保持开放状态，与其他系统进行交流。这意味着其他公司可以与这些应用程序内的数据和流程进行互动，建立协作。最后，为了长期支持公司，低代码平台需支持软件应用程序的发展进化。软件的维护也应该像创建新软件时一样简单。如果低码平台不符合这些设计原则，那么用户用该平台创建的软件就不能满足客户的期望，或者无法按照客户的需求进行优化。
负责设计低代码平台的软件架构师在为客户解决这些问题时面临着巨大的挑战。在我博士研究期间，我主要从软件架构师的角度，收集资料并研究了能够帮助低代码架构师的解决方案。本文总结了建立下一代低代码平台的最重要的贡献和建议，如果想查看全文，可以点击这里查看我的论文《低代码平台的演变》。
基于云的架构
为让 LCP 能够帮助公民开发者开发越来越大且复杂的软件系统，他们需要引入能够开发大型系统的方法。这些方法的例子是架构模式，如微服务架构风格（MSA） 和事件驱动架构。这两种模式都提供了大型系统模块化的新方法。改善模块化的抽象对于管理日益复杂的大型软件系统至关重要。例如，MSA 风格背后的逻辑是开发一些较小的（因此不太复杂的）相互连接的软件系统，而不是大型的单体系统。事件驱动架构保证了软件系统的不同部分（如微服务）以异步的方式进行通信。这导致了一个松散耦合的系统，其中的各种微服务可以自主开发。开发团队可以重点关注系统中较小的部分，降低任务的复杂性。
事件源和命令查询责任隔离（CQRS）是两种特定的架构模式，可以应用于 MSA 风格和事件驱动的架构。虽然这些模式有很多优点，但对于需要解决软件进化问题的软件架构师来说，可利用的知识和工具很少。我们在论文中提出了几个关于事件源系统进化的技术，这些技术是我们从对多个工程师的采访中汇编的。软件架构师可以使用这些技术在低代码平台中创建无缝升级。
API 管理
不能把软件应用看作是孤立的系统。他们通过参与软件生态系统，与外部世界相连。软件生态系统由软件生产组织（SPO）使用，通过与第三方合作，帮助客户提高其软件的价值。这些生态系统是围绕软件平台形成的，而软件平台又是由软件平台协调者管理的。软件平台是一组协作服务于软件和服务市场的组织。
在这些软件生态系统中，应用编程接口（API）是不可或缺的。因此，API 管理是这些协调者的重要活动之一。扩展软件系统的第三方依赖于这些 API，因此，这些 API 的可用性和可扩展性至关重要。如果 LCP 想要支持软件生态系统的工程，他们需要提供 API 管理能力。因此，LCP 的软件架构师需要计划和开发 API 管理能力，以便 LCP 能够发展成熟。
我和我的同伴不仅提出了一个 API 管理实践的一般成熟度模型，即 API-m-FAMM，还调查了四个有名的低代码平台，评估了这些平台对 API 管理实践的支持现状。我们的结论是，虽然它们有一些必要的能力，但总的来说，它们还没有关注对公民开发者开发 API 和发展软件生态系统的支持。在未来几年，低代码平台需要从应用建设平台发展为平台建设平台。
变化影响分析
对于开发低代码平台的软件架构师来说，最大的挑战是对变化影响的分析。在一个低代码平台内，软件工程师以及公民开发者所做的改变会对平台的其他部分产生影响，包括生态系统内的其他软件工件。虽然有些变化是无害的，但有些变化需要数据转换。因为低码平台所提供的抽象属于更高层次，所以对这种影响的分析是困难的，但对于使用低码平台的公司来说，这种分析对于保持对应用程序的控制是至关重要的，LCP 应该支持对受影响的组件及其（半）自动进化的确定。
在我们的最终研究中，我们提出了低代码开发平台的影响分析框架。这个框架支持软件进化的过程。软件架构师可以在低代码平台的设计中使用它，确保公司对其系统保持控制。
展望未来
论文只是开始，后续还有很多工作。我应该提供更多的知识、指南和工具供软件架构师使用，从而支持低代码平台的设计。这能简化他们的工作，让他们专注于平台的鉴别性特征：可以创建的应用程序和平台类型。
Michiel Overeem 是 AFAS 软件公司（一家荷兰的 ERP 公司）的首席软件架构师， 他带领一个团队负责 ERP 云平台下的低代码平台。他于 2022 年获得博士学位，其论文是关于低代码平台的演变。他的主要兴趣是低代码平台、事件源系统和微服务架构风格。
原文作者：Michiel Overeem
原文链接：https://modeling-languages.com/evolution-low-code-platforms/
