六边形架构是一种用于设计软件应用程序的架构模式。近年来，它的受欢迎程度有所增加，因为它是传统分层架构的替代品。

分层架构有什么问题？

这种架构模式应用 SoC（关注点分离）原则将我们的组件分解为层，每一层都有不同的职责。通常，有 3 层：

1. 表示层，其中包含用户界面。
2. 业务层或领域层，包含业务逻辑。
3. 持久层，处理数据库操作。

在应用这种架构模式时，我们面临着层与层之间的依赖关系，即每一层都依赖于紧接其下的层。该模型未能表明我们可以与多个数据库交互或根本不与任何数据库交互。此外，表示层没有考虑到用户与我们的应用程序交互的方式可能不止一种。

六边形架构如何克服分层架构的弊端？

该模型将所有业务逻辑置于应用程序的核心，抽象出任何类型的外部依赖。这种隔离使得逻辑更容易测试和维护。

应用程序现在拥有一个或多个处理用户请求的输入适配器，而不是表示层。类似地，现在我们有一个或多个输出适配器来调用外部应用程序或服务，而不是持久层，例如 Amazon S3 中的文件存储、SendGrid 等电子邮件服务，或者更常见的是数据库。

业务核心有一个或多个端口。端口定义了一组操作，允许核心与适配器进行交互，从而与应用程序外部的内容进行交互。正如我们有两种类型的适配器，输入和输出，有一个输入端口和一个输出端口。输入端口是内核公开的供外部应用程序访问的 API，而输出端口是允许内核使用外部服务的接口。

输入适配器通过调用输入端口来处理来自外部世界的请求。这方面的一个例子是实现 REST API 或 gRPC 服务器的 Spring 控制器。

输出适配器实现了一个输出端口，该端口通过调用外部应用程序或服务来处理来自业务核心的请求。一些示例是执行数据库操作的 DAO（数据访问对象）类，或使用电子邮件服务的 Spring 组件。

到目前为止，我们已经看到了与六边形架构相关的概念。现在，让我们将理论付诸实践，并使用 Kotlin 构建一个 Spring 应用程序。

首先，我个人喜欢将项目分为三个主要包：

• “core”包，包含与核心业务相关的组件。
• “ ports ”包，包含将业务核心与外界通信的输入和输出组件。
• “ config ” 包，用于启动应用程序和处理其内部行为所需的所有配置。
•  

构建核心

放置我们的Article实体。请注意，它使用普通的 Kotlin（或 JAVA），但完美地代表了业务实体。

package com.Github.manerajona.blog.coreimport java.time.LocalDateTimetypealias ArticleId = Longdata class Article(    val id: ArticleId?,    var title: String,    var headline: String,    var content: String,    val addedAt: LocalDateTime?)

其他包括：
 

• ArticleRepository接口，它允许业务核心与外部服务进行通信。
• ArticleService接口，它允许外部应用程序与业务核心进行通信。在usecase包中，ArticleServiceImpl 类 扩展了ArticleService并包含实际的业务逻辑。

数据库适配器的输出端口

ports/output/jpa包包含将数据持久保存到数据库中的组件。

包含：

• 基于core实体的ArticleJpa类。
• 从 Spring JPA 库扩展JpaRepository的ArticleJpaRepository类。
• ArticleDao类扩展了ArticleRepository，允许业务核心获取和持久化数据。

REST 适配器的输入端口

最后，ports/inputs/rs包包含 Rest Controller，暴露端点以供外部应用程序使用。

为什么架构很重要？

设计软件时存在一组基本要求，称为服务质量要求。这些要求定义了我们在构建高质量软件的过程中必须解决的一些权衡问题，例如可伸缩性、可靠性、可维护性、可测试性和可部署性。

架构很重要，因为如果我们在选择时足够明智，那么适合我们项目的架构模式将帮助我们的软件达到预期的质量，并且也许可以让我们免去一些麻烦。

示例代码可在GitHub上找到。