云生态系统的六边形架构

为了帮助管理云计算的复杂性，麦当劳的开发人员正在使用六边形架构模式--请继续阅读，了解该解决方案的具体内容。

作者：解决方案架构师经理 Adam Rice

随着越来越多的公司进行数字化转型和系统现代化，开发人员面临着在各种分布式系统之间进行集成的日益复杂的问题。

在多篇系列博客中，我将详细介绍一种潜在的解决方案，以帮助管理云生态系统中的复杂性： 六边形架构。

下面我将解释

1. 什么是六边形架构
2. 架构的组成

什么是六边形架构

六边形架构是一种将外部系统与核心应用程序分离的架构模式。

想法很简单。从六边形开始。应用端口和适配器，对吗？

六边形有六条边。从理论上讲，我们的形状可以有 100 条边来解释应用程序中的所有交互。

六边形本身并不意味着什么。它只是提供了一种简洁的方式来讨论和解释应用程序的端口、适配器和域。

这种形状提供了一种方法来解释应用程序流程的一小部分，而不会让受众对应用程序的全貌感到不知所措。从本质上讲，它限制了设计者一次只能设计或解释一小部分易于理解的内容。

让我们从内部开始

应用领域位于六边形内部。我们所说的领域是指遵循领域驱动设计（DDD）的原则，我们的业务逻辑不会泄露到六边形之外。就上下文而言，领域驱动设计

1. 通过定义与特定业务相关的模型来关注主要问题。
2. 使用所有团队成员都能理解的通用语言。
3. 定义封装领域模型的有界上下文。

按照 DDD 原则，为了这篇文章的目的，我使用下面的流程提出了以下领域。

假设我们正在构建一个新的应用程序，允许用户通过网站将文件上传到一个中央资源库进行共享。

以下是一些基本的应用要求： 

1. 文件由经过认证的用户通过网站上传。
2. 文件是为程序上传的，也可以说是为目的上传的。
3. 程序/用途是一组预先配置的文件规范，文件必须遵守这些规范。
4. 程序规则规定的内容包括

- 可上传的文件类型

- 字段数量

- 其他要求，如加密或压缩文件

- 文件必须符合特定规格才能被接受。

1. 用户必须有权限（授权）上传特定程序的文件。

回到域

域代表应用程序的关键业务逻辑，它允许用户将文件上传到存储库，以便与其他各方共享。请注意，下面的域只包括上传者、上传者的授权和要上传文件的文件规格。

蓝色矩形称为实体，与蓝色域一起代表满足我们的功能要求所需的结构。

一个更详尽的领域模型可以包括上传或下载文件的下载器和文件配置细节，以及可能应用的数据质量配置。可以说，所有这些都可以进一步划分为子领域，但为了简洁起见，我们将坚持使用当前的示例。

从逻辑上讲，我们的六边形现在看起来是这样的：

还记得我们之前说过的话吗？六边形架构的原则之一是，领域不会泄露到六边形之外，也不需要了解外部世界的任何情况。

此时，理论上我们可以从业务逻辑功能的角度编写满足该应用程序基本要求的代码。这将是最纯粹的应用程序代码开发。然而，这对我们并没有什么帮助，因为业务逻辑被包裹在六边形的外部边界内。

我们需要一些输入和输出，因此我们现在要对如何与我们的领域进行交互做出一些假设。

最简单的假设如下

用户以请求信息或上传文件的形式提交数据。输入

这些数据经过验证、转换并存储在某个地方。输出

我们需要与该域进行交互，使其能够完成工作，即授权上传者、接受文件并检查文件规格（基于程序/用途）的有效性。

让我们稍作休息，因为上述两个步骤带来了这种架构的另一个好处。在这种纯粹的形式下，可以实现单元测试或测试驱动开发（TDD）。

编写自动化单元测试，在开发过程中或进行增强时运行，可以降低引入错误的风险，提高代码质量，尤其是在单元测试作为代码签入和部署活动的一部分运行时（想想 CI/CD）。

如果遵循TDD，那么在编写任何功能代码之前，首先要编写代码中的单元测试。测试会失败，因为还没有编写任何功能代码。因此，要编写满足测试要求的功能代码。然后再编写下一个测试，接着编写功能代码，然后再编写测试，依此类推。

本周就到这里。现在我们已经确定了什么是六边形架构，并创建了领域模型，下周我们将探讨如何连接端口和适配器，以便开始管理架构的复杂性。