六边形架构：管理复杂性的解决方案

六边形架构是什么？

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

其思想很简单。我们从一个六边形开始。然后应用端口和适配器，对吧？

六边形有六个边。六边形的形状本身并没有特别含义。它只是提供了一种清晰的方式来讨论和解释应用程序的端口、适配器和领域。

这个形状提供了一种解释应用程序流程中小块内容的方式，而不会让观众对整个应用程序的图景感到不知所措。它本质上限制了设计者一次只设计或解释小块容易理解的部分。

从内部开始

应用程序领域位于六边形的内部。当我们说领域时，我们指的是遵循领域驱动设计（DDD）原则，并且我们的业务逻辑不会泄露到六边形外部。为了上下文，DDD：

• 专注于通过定义与业务特定部分相关的模型来解决主要问题。
• 使用所有团队成员都能理解的通用语言。
• 定义了一个边界上下文，其中封装了领域模型。

遵循DDD原则，为了本文的目的，我使用以下过程提出了以下领域。

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

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

• 由经过身份验证的用户通过网站上传文件。
• 文件是为程序上传的，或者换句话说是为了某个目的上传的。
• 程序/目的是一组预先配置的文件规范，文件必须符合这些规范。
• 程序规则指定一些内容，比如：— 可以上传的文件类型— 字段数量— 其他要求，比如加密或压缩文件— 文件必须符合某些规范才能被接受。
• 必须授权用户以上传特定程序的文件。

返回领域

领域表示应用程序的关键业务逻辑，允许用户将文件上传到存储库以供其他方共享。请注意，以下领域只涵盖了上传者、上传者的授权和要上传的文件的文件规格。

蓝色矩形被称为实体，它们连同蓝色字段一起表示满足我们功能要求所需的结构。

一个更全面的领域模型可能包括已上传或已下载文件的下载者和文件配置详情，以及可能应用的数据质量配置。可以争论说这可以进一步划分为子领域，但为了简洁起见，我们将坚持当前的示例。

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

众所周知六边形架构的原则之一是领域不泄露到六边形外部，也不需要了解外部世界的任何信息。

在这一点上，我们可以从理论上写出满足这个应用程序基本要求的代码，从业务逻辑功能的角度来看，这将是纯粹的应用程序代码开发。然而，这并不能帮助我们太多，因为业务逻辑被包装在六边形的外边界之内。

我们需要一些输入和输出，所以现在我们做一些关于我们如何与领域交互的假设。

在最简单的形式下，这些假设听起来像这样：

• 数据以用户的请求形式提交，可以是信息请求或上传文件。（输入）
• 这些数据经过验证、转换并存储在某个地方。（输出）

我们需要与这个领域交互，以便它能够完成其工作，即授权上传者、接受文件并检查文件规格（基于程序/目的）是否有效。

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

编写自动化单元测试可在开发过程中或进行增强时运行，可以减少引入错误的风险，提高代码质量，尤其是如果单元测试作为代码检入和部署活动的一部分进行运行（考虑持续集成/持续交付）。

如果你在遵循TDD，你会先在代码中写一个单元测试，然后再写任何功能性代码。该测试将失败，因为你尚未编写任何功能性代码。然后，你编写满足测试的功能性代码。接着你编写下一个测试，然后功能性代码，然后测试，依此类推。

这就是本文的全部内容。现在我们已经了解了什么是六边形架构，并创建了我们的领域模型，下一篇我们将探讨如何连接端口和适配器，使架构能够开始管理复杂性。