低代码平台是否能够实现真正复杂的业务流程的逻辑

低代码已经成为商业交付解决方案的发展趋势,这一点是没有争议的。然而,低代码传统上并不是开发处理复杂业务任务的系统的首选。与低代码开发相关的主要缺点之一是所创建应用程序的功能有限。

在本文中,我们将讨论低代码平台是否能够实现真正复杂的业务流程的逻辑

低代码是一种业务应用程序开发方法,它涉及将现成的框架组件组装到业务系统中,同时最大限度地减少脚本编写。

这种方法已被证明可用于为标准业务任务提供解决方案,其中低代码平台的开发人员本身提前预测了所需的功能。例如,CRM系统 应用程序中的每个功能确实可以在不编写一行代码的情况下实现。

然而,在现实生活中,企业往往有超出低代码平台范围的独特需求。因此,我们面临无法将基于低代码的解决方案完全适应特定业务逻辑的问题。有没有什么方法可以在不放弃低代码优势的情况下解决这个问题?

一切都取决于框架

鉴于上述限制,传统观点认为更复杂的计算或算法需要使用低级语言进行编程。例如,许多会计系统的开发人员会说,复杂产品的成本计算——或处理可能受数十种因素影响的工资单——需要“用 C++ 或其他编程语言进行一些收尾工作”。这意味着必须聘请经验丰富的编码人员,以及维护自定义集成界面。

尽管有传统智慧,复杂业务任务的低代码解决方案既可行又广泛使用。所需要的只是开发平台允许对确定其内置对象如何运行的算法进行深入修改。它将使开发人员能够为任何可以想象的复杂度的场景实现业务逻辑,而无需求助于低级编程。

领域驱动设计

这个问题是所有业务开发的特征,导致了领域驱动设计 (DDD) 的产生。DDD 涉及创建构成现实世界主题领域(领域)模型的对象的最佳抽象和封闭系统。一个面向 DDD 的开发框架的核心必须是一系列模板(对象)和交互,这些模板(对象)和交互是特定于它将被应用的领域的。

因此,使用这种框架的开发人员可以使用现成的类来开发最终产品。代码的逻辑必须与现实世界的主题领域相对应。这种对应是由于领域专家和开发人员使用的统一语言。在领域驱动设计中,这被称为无处不在的语言。

领域专家是了解开发人员必须建模的业务流程如何工作的人。他们可能是分析师、经理或高管。

另一方面是开发人员和架构师,他们直接参与实施应用程序和自动化,并且可能不了解业务流程。

需要领域专家和开发人员之间的持续互动来同步、商定目标和规划开发过程。这种交互使用无处不在的语言来避免歧义和误传。

所有工件都尽可能使用通用语言的术语进行描述,从项目要求开始到代码结束。

领域驱动设计与低代码定制灵活性有何关系

来自传统开发世界的概念——类、数据库表、服务器、库——被转移到框架的“引擎盖下”。开发人员使用反映业务逻辑的平台对象——目录、文档、登记簿(分类帐)、会计科目表等。

开发人员从一组相当有限的现成类中进行选择,并在可视化编辑器中设置类的属性。因此,开发人员“告诉”平台应用程序将是什么——它将包含哪些实体,它们之间的关系将是什么。然后平台本身创建数据库结构,读取/写入数据库,并绘制默认用户界面。

但是,在您无法预测业务逻辑的情况下,不能完全排除编码本身。例如,计算立法变更后的税收、实际成本计算、折扣等。

在1C: Enterprise 平台的情况下,DDD 原则的应用扩展到内置的 1C 编程语言。它是一种领域特定语言(DSL),允许使用特定于业务的逻辑。1C 语言中的简单表达式使开发人员能够操作特定于会计的对象,例如文档、目录和报告,尽可能从 DBMS 和操作系统级别的编码中抽象出来。

即使不擅长财务审计或会计等领域,软件开发人员也可以使用统一的数据模型和现成的会计模板来设计应用程序。

得益于现成的模板,无需“从头开始”发明任何东西或编写程序。同时,由于内置 DSL 能够修改模板功能底层的算法,因此系统的功能没有硬性限制。例如,您可以在不连接第三方解决方案和编程语言的情况下实现复杂的计算机制。

因此,开发人员不必牺牲定制灵活性和使用低代码的应用程序范围。

阅读推荐:低代码为什么能显著减少开发时间?