敏捷微服务在几分钟内

通过将您的敏捷计划与低代码微服务相结合，在短短几分钟内构建出您的敏捷计划以部署微服务。以下是一个出色的例子。

在本文中，我们将解决以下问题：

1. 敏捷宣言：将可运行的软件的关键敏捷宣言原则，作为客户协作和变更响应（快速迭代）的基础是一个正确的目标，但关键的挑战是：现在如何获得可运行软件的敏捷宣言？
2. 敏捷，低代码微服务：传递可运行程序的关键创新，目前的做法是：一个应用程序会从预期软件设想，类似将电子表格类规则链接到敏捷故事的声明式业务逻辑，以及观点和API几个方面去创建系统。我们将展示这些如何推动客户协作，并使我们能够快速响应变化。
3. 例如：它们如何在（几乎）几分钟而不是几周内提供微服务。这个例子非常出色：一个应用服务接口能够与不同用户，用户界面，用于多表派生和验证的业务逻辑以及基于消息的内部集成框架相融合。

业务敏捷性：战略竞争优势

数字转换已被广泛接受为在当今应用经济中成功竞争的要求。在基于API和微服务技术的现代软件体系结构中，将您的系统和Web /移动应用程序与业务合作伙伴和现有系统集成在一起。

但除了整合以外，我们需要业务敏捷性 - 快速创新提供新服务，维持互动，并适应业务/监管变化。这是一种战略竞争优势。

我们不仅需要对框架，向导和IDE进行渐进式改进，还需要更好的改进。

“将来，创建一个系统就像设想它一样简单。” - 大卫Shutt

敏捷宣言：与工作软件协作，经常迭代

敏捷宣言清楚地表明，我们需要做的第一件事就是从根本上重新考虑我们开发软件的方法。它比从瀑布移动到迭代要深得多。

敏捷方法取代了以前的计划方法，如'用例法'和‘软件统一过程’。让我们来探讨一下敏捷宣言中的一些关键原则：

敏捷软件开发宣言

工作软件

如下所述，在项目的早期获得工作软件，建立了客户协作和变更响应的其他关键组成部分。

基于工作软件的客户协作

与业务用户不理解的技术图（数据库图，泳道图等）不同，敏捷值基于工作软件进行协作。这是真实的 - 经验表明，操作屏幕进行交流比文档或线框更有效地传达多倍信息。这减少了需求风险，并提高了业务敏捷性。

响应变化：快速迭代

瀑布造成致命的假设是，需求要求不会改变，并且无效沟通的情况很少发生。敏捷认为需求变化和沟通不畅的情况经常发生，因此快速迭代成为软件开发过程的一部分。

但 - 开发自动化？

该方法在项目早期取决于工作软件。但是，我们如何获得？我们需要敏捷开发自动化来补充和支持我们的敏捷方法。

敏捷低代码微服务：关键创新

敏捷过程依赖于基于工作软件的客户协作。我们不仅需要速度，而且要使用赛车说法，提前提速。这要求在目前的实践中进行几项关键创新，在下面的部分中进行了描述。

现在开发软件 - 首先应用于面向结果的协作

客户协作基于商业用户的角度来看最为有效，而不是像数据库图表这样的技术工件。我们都有过谈话，文件，图表都与屏幕相邻的经历。不只是一个线框，而是工作屏幕。这是我们正在寻求的结果，并极大地改善了协作。

使用基于ORM，路由和控制器的手工编码方法创建屏幕非常缓慢，而且对于商业用户而言过于复杂。许多人转向低码方法。

但即使是低代码方法也需要首先定义数据库，基于抽象概念（如主键）和基于外键的关系。这仍然太复杂。

为什么不让工作屏幕成为发展的基础？首先，不要使用数据库，而要使用客户方法 - 从运行（空）应用程序开始，使用设备来模拟结果，并使用它来自动执行数据库设计。

应用程序通过界面操作数据库

例如，设想从一个正在运行的（空的）应用程序开始，并添加一个按钮来添加一个表。我们点击它，并添加客户表。系统使用一些默认字段（例如，客户姓名），屏幕字段和样本行创建表格 - 所有这些都来自始终运行的应用程序。

更多按钮使我们能够将字段添加到客户表/屏幕。在用户心目中，表格和屏幕之间没有区别 - 他们关注业务成果。

现在我们添加一个订单网格（列表）到我们新创建的客户页面。系统很容易推断订单对客户有外键，并自动创建表格和外键。我们将在下面看到一个例子。

结果不是一个线框，而是工作软件：不仅是多屏幕用户界面，还有底层数据库模式和持久性逻辑。准备好让商业用户进行协作，这样你就可以“快速失败”并在项目开始时发现问题，而不是结束。

声明式业务逻辑

后端业务逻辑是任何应用程序验证，计算和持久性的重要部分。除了整合之外，它还是传统应用程序的一半。这是应用程序（或API）表面下的冰山。

微服务-应用程序和业务逻辑

低代码方法通常使用可视化编程来解决这种逻辑问题。虽然这些是有吸引力的，但它们并不处理所需的逻辑规模，因为它们是必要的。显着的敏捷性需要更强大的方法：声明式。

维基百科将声明性定义为表达逻辑，没有控制流 - “是”，而不是“如何”。该概念最成功的应用是反应逻辑，即电子表格的概念基础。这些表达了没有控制流的复杂逻辑，自动执行依赖和调用：

表1 - 声明逻辑与命令码。

电子表格式反应逻辑可适用于数据库领域：

• 将派生规则与数据库列相关联，自动链接的执行顺序基于系统检测到的依赖关系。为了解决大多数现实世界的问题，这些问题需要包括多表规则（例如，“客户余额是未付订单金额的总和”），以及底层SQL的全面自动化（和优化）。
• 为表提供多列验证表达式（例如，“balance <credit-limit”）
• 集成到API处理中，以便所有PUT，POST和DELETE 按照反映其依赖关系的顺序自动调用基础派生和验证逻辑。
• 可扩展性，以便可以添加命令代码来集成现有代码，并调用外部服务（Web服务，电子邮件等）。

反应逻辑是低代码方法的主要扩展。它将典型的面向数据库的业务逻辑的简洁性提高了40倍（原文如此）。我们将在下面的示例中进一步探讨它。

通过自动调用和排序来响应变化

工作软件正在促进客户协作，但另一个关键的敏捷原则是响应变更。这是由声明式反应逻辑支持的：由于执行是自动排序和优化的，因此迭代周期仅包括更改规则。系统确保您的逻辑按照正确的顺序执行。

点击式API和消息

现代软件架构是为了与使用API​​和消息传送的合作伙伴和内部系统集成而构建的。这些也形成了支持交互式网络和移动应用程序的通用后端。API应该是自动的，可以通过指向和点击进行定制，而不是路由和控制器。

客户协作

敏捷宣言强调客户协作是确保系统满足实际业务需求的关键要素。这有几个要素。

面向业务的焦点

作为开发人员，我们必须解决许多潜在的关键技术因素。这些包括数据库设计（例如图表），ORM映射，性能，安全性等。

和技术一样重要的是，商业隐喻对于与商业用户合作至关重要。这意味着线框和电子表格式的逻辑，而不是外键等。

现在工作软件：应用优先

我们上面提到，协作和迭代的最佳基础是现在的工作软件......基于设想的结果，而不是数据库内部或非操作线框。

故事/逻辑可追溯性

作为用户故事，敏捷非常擅长捕捉非可视化的需求。例如，

“作为商业用户，我希望系统能够确保客户的余额永远不会超过他们的信用额度。”

这是IT实施者和协作业务用户的重要系统信息。它不仅应该作为系统实现的一部分被捕获，还应该映射到实际实现该需求的对应逻辑规则。这个特别的故事映射到这2条规则：

“customer balance is the sum of the unpaid order amounts” “balance < credit-limit”

捕获此映射有助于客户协作和需求可追溯性，对商业用户和IT都是透明的。它是双向的 - 您可以找到故事的规则，或者规则的故事（考虑更改时的影响分析）。我们将在下面看到一个例子。

敏捷低代码实例：示例应用程序

让我们使用敏捷低代码微服务为新数据库构建一个微服务。想象一下，市场部门需要一个系统，设想如下所示的线框/功能：

1. 合作伙伴发布代表会议的API，可供我们选择参加展览（展位）和会谈。这些存储在我们的（新）数据库中。
2. 显示的用户界面使我们的团队能够选择我们想要“使用”的展览/展位。系统执行业务逻辑以确保其成本不超出预算。
3. 批准后，会将MQTT或Kafka消息发送给会计。

市场部门系统需求图

图1 - 营销系统要求

我们可以使用敏捷低代码微服务方法在20分钟内构建整个系统，如下所示。为了明确，我们将使用CA Live API Creator（LAC）。

现在工作软件：UI /架构API创建

我们当然可以使用现有的数据库工具来创建一个数据库，并使用一个画图工具来创建一个UI。但是，这需要一些可能不熟悉的专业知识。而且，即使是专家也很乏味。与我们正在寻求的结果相比，这会分散我们的技术集中度。

现在的工作软件意味着我们从结果开始，以业务术语来说 - 用户可以用它来想象他们的系统的屏幕。我们通过选择‘App First’选项从API创建页面创建我们的模式。

应用程序创建

图2 - 数据库创建。

这将在空白屏幕上打开Data Explorer，并使用按钮来创建表格和字段，以便我们可以“绘制”我们的应用程序。我们首先添加会议表：

添加会议表操作示例图

然后，我们可以添加字段（如预算）和相关的会话表，如下所示：

添加字段

图3 - 模式创建。

因此，通过勾画我们的屏幕（结果），我们获得了工作软件以促进协作：

• 活动的用户界面 - 可以读取和写入数据
• 一个数据库，系统自动执行诸如键，AutoNum字段，外键等文书细节。这使我们能够专注于业务问题......在商业术语（表单）
• 一个默认API，与我们的模式相匹配。这扩大了API First的概念，使其成为进行时工作软件的自动结果。我们将看到如何为数据独立层定制下面的API的“形状”。（未显示，我们也可以保护API，使其仅适用于授权角色）。

或者：从现有数据库开始

快速一边：虽然这个例子着重于创建一个新的数据库，但是从现有数据库开始（图2中的第一个选项）通常是这种情况。在这种情况下，系统会自动构建一个UI，如下所示（来自熟悉的Northwind）。

从现有数据库创建UI界面

这是一个非常全面的用户界面，包含主/细节，过滤，排序，可更新的网格，屏幕过渡等。定制也受支持（我们将在以后的文章中更详细地探讨这一点）。

图4 - 从数据库创建的默认应用程序。

在默认的应用程序创建之后，您可以创建API，逻辑和集成，如以下各节所述。尽管我们不会在本文中讨论，但共同的第一步是指定API访问授权，包括直到行/列级别的细粒度安全性。

API创建：点击并点击

与现有数据库相同，数据库创建将创建一个默认API。但是，如图1（特征1）所示，我们需要创建一个自定义端点，以便将我们的业务协议与我们的合作伙伴相匹配：

1. 嵌套文档（加入），包括会议，会谈和展览
2. 使用映射和转换逻辑来选择所需的字段，并将它们别名（我们的API协议与我们的模式不匹配）

我们的数据抽象层是选中并且点击：我们创建一个资源，给它一个名字（PartnerPost），选择表（连接是使用模式信息自动创建的），并且选择/别名我们的字段，如下所示：

为表创建一个字段

图5 - API创建。

创建故事，导入LAC

正如敏捷所预见的那样，工作软件引导客户协作。协作的一部分是数据模型（“等待！客户可以有多个地址”），这通过工作软件屏幕变得非常明显。合作的一部分是业务逻辑（“等等，我们需要检查预算！”）。

这些要求必须被捕获，优先和正式化。当然，一个很好的方法是使用敏捷工具，这里是CA Agile Central：

敏捷工具

真正的力量从将它们导入LAC开始。由于这两个产品都支持API，我们创建了一个简单的API来填充LAC主题（故事导入API可从CA获得）。这些在下面显示为我们规则右侧的彩色矩形。（当然，我们可以直接在LAC中手动创建主题）。

逻辑创建：类似电子表格的声明式业务逻辑

由于用户将展览和会谈标记为“已用”，因此我们需要将其成本累积到会议中，并且不超过预算（请参阅图1，步骤4）。典型的多表业务逻辑，作为附加到表和列的业务规则来捕获，如下所示：

声明式业务逻辑

图6 - 逻辑。

彩色的盒子是故事。如上所述，您可以直接输入它们，或从项目管理系统（如Agile / Central）导入它们。然后您将它们附加到您的规则中，提供需求追踪。

创建验证规则很简单：

1. 点击创建规则，然后从随后的列表中选择“验证”规则类型（请参见图7：选择规则类型），并指定用于验证的表格（会议）。
2. 声明验证规则，如图8所示，验证规则：
   • 代码是JavaScript。
     • 行表示已更改的会议行，提供对字段和相关数据的访问。它是您的对象模型，由系统根据模式自动创建和维护
     • 由于系统知道表中的字段（列），因此它可以提供代码完成，如下所示
   • 规则在更新时自动调用。如果验证返回false，则事务将回滚，并返回一个异常并显示错误消息。

创建验证规则

图7 - 选择规则类型。

选择规则类型

图8 - 验证规则。

如本例所示，规则是相互依赖的：验证依赖于其他计算字段，例如ExhibitsCost。回想一下图6：

ExhibitsCost =  总额（ Exhibits_List 。使用金额=  真实的 金额）

系统甚至可以跨表格自动转发链接更新，并按照依赖关系确定的顺序进行更新。因此，设置展品将触发展品成本调整，这将触发预算检查。

我们声明汇总规则如下所示：

• 在规则屏幕上（图6），点击创建规则
• 在随后的选择规则类型屏幕上（请参见图7），选择总和

输入总和规则，如下所示：

输入规则

图9 - 总和规则。

消息

我们差不多完成了。我们最后的要求是在会议行被批准时发送消息给会计。我们将其定义如下：

• 在规则屏幕上（图6），点击创建规则
• 在随后的选择规则类型屏幕上（图7），选择事件（有点像触发器，除了它在中间层运行，并用JavaScript表示）
• 消息传递是一种熟悉的模式，因此系统提供了一个代码示例，如下所示; 我们只是简单地修改它以适应我们的域名。

尽管这只是5行代码，但还有很多。我们将在未来的论文中对其进行审查。

图10 - 消息规则。

低代码，而非代码 - 可扩展性，利用现有代码

这个消息事件说明了一个重要的点 - 虽然关联性逻辑功能强大，但您始终需要在代码中执行某些操作。所以，通过JavaScript来实现低代码。

这不仅提供了重要的可扩展性，还使您能够利用在JVM中运行的现有软件。基于服务器的JavaScript可以调用Java和运行在（服务器端）JVM中的其他代码。

简介：一个现代化的软件工厂

现代软件工厂不仅仅是现有工具的集合。它是一套完整的工具，每个工具都提供自动化功能，以令人难以置信的速度将商业理念转化为成果。如下所示，我们的工厂使用公认的工具，从敏捷计划到用于微服务的DevOps。

本文讨论了在中间构建阶段应用自动化。Agile Low-Code以前被假定为需要手动编码，它引入了自动化创新：现在创建工作软件的App First方法和声明式业务逻辑。它集成到您​​的工厂中，具有敏捷故事输入和微服务输出。

让我们通过评估我们的总结：

• 成果 - 我们提供了什么？
• 敏捷映射 - 这个过程是否适合敏捷方法？
• 关键技术 - 这里有什么不同？

业务成果：分钟，而不是几周

最引人注目的是，我们在20 分钟内将我们的想法变成了商业成果，而不是几周。颠覆性业务敏捷性。我们的结果是现代软件架构：可部署的微服务，包括我们的API，逻辑，UI和基于消息的集成：

回顾一下，我们创建了一个完整的基于微服务的系统：

• 我们画了我们的应用程序想法，它创建了我们的工作用户界面，数据库和默认API
• 我们宣布自定义终端处理来自合作伙伴的API请求
• 我们将我们的敏捷故事导入LAC
• 我们为逻辑声明类似电子表格的业务规则，以累积成本并检查预算
• 我们使用JavaScript事件将正确格式的MQTT（或Kafka）消息发送到另一个系统

敏捷方法：现在开发工作软件，用于客户协作和迭代

敏捷的核心目标是迅速达到正确的结果。我们已经证明，手动开发很慢并且使协作复杂化，但敏捷微服务方法可以缩小差距：

1. 体系结构：通用服务和持久性元素是自动化的，释放您专注于逻辑...
2. 逻辑：以面向业务的术语进行声明，明显更加简洁并促进协作：
   1. UI：App First根据设想的结果创建工作软件（屏幕和数据库）
   2. 逻辑：类似电子表格的面向业务的规则自动执行调用，排序，持久性和优化，可追溯到原始的敏捷故事
   3. API：针对系统/移动应用程序集成的Point and Click数据抽象层

敏捷低代码微服务方法远远超过将敏捷故事与传统开发方法和工件集成在一起。受敏捷宣言核心租户（左栏）的启发，我们推出了四项关键创新，使我们能够在几分钟内提供我们的微服务：

表2 - 敏捷宣言原则激发了敏捷微服务在关键时刻的创新。

在以后的文章中，我们将进一步探讨逻辑创建和操作，API和微服务创建，用户界面创建和部署的细节。

一探究竟

如我们试图做出这样的描述和示例一样清楚，这是绝对不可替代的。如果您想自己查看敏捷低代码微服务，请查看此视频，并在此处获取CA Live API Creator的试用版。在几分钟内，您就可以连接到其中一个数据库以及创建的Web App和API。