SpringBoot六边形架构案例

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

分层架构有什么问题?

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

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

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

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

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

应用程序现在拥有一个或多个处理用户请求的输入适配器,而不是表示层。

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

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

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

输出适配器实现了一个输出端口,该端口通过调用外部应用程序或服务来处理来自业务核心的请求。一些示例是执行数据库操作的

DAO(数据访问对象)类,或使用电子邮件服务的 Spring 组件。

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

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

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

构建Core

放置我们的Article实体。请注意,它使用普通的 Kotlin(或 Java),但完美地代表了业务实体。

<b>package</b> com.github.manerajona.blog.core

<b>import</b> java.time.LocalDateTime

typealias ArticleId = Long

data <b>class</b> Article(
    val id: ArticleId?,
    <b>var</b> title: String,
    <b>var</b> headline: String,
    <b>var</b> 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 上找到。

 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
六边形架构,也称为端口适配器架构,是一种软件架构模式,主要用于分离应用程序的业务逻辑和外部依赖。其目录结构如下: ``` app ├── adapters │ ├── inbound # 应用程序的入站适配器 │ │ ├── controllers # 控制器层,处理HTTP请求或其他协议的请求 │ │ ├── gateways # 网关层,处理与外部系统的通信 │ │ ├── presenters # 表示层,负责将业务逻辑的结果转换为适合显示的格式 │ │ └── usecases # 用例层,提供可重用的用例操作 │ └── outbound # 应用程序的出站适配器 │ ├── database # 数据库层,处理与数据库的交互 │ └── messaging # 消息队列层,处理与消息队列的交互 ├── config # 应用程序的配置 ├── domain # 应用程序的业务逻辑 │ ├── entities # 实体层,定义应用程序中的核心概念 │ ├── repositories # 仓储层,定义实体的操作接口 │ └── services # 服务层,提供应用程序的核心业务逻辑 └── main.go # 应用程序的入口文件 ``` 其中,`adapters`目录包含了应用程序的入站和出站适配器,用于处理来自外部系统的请求和与外部系统的通信。`inbound`目录包含了控制器、网关、表示和用例层,负责接收和处理来自外部系统的请求,并将其转换为业务逻辑操作。`outbound`目录包含了数据库和消息队列层,负责与这些外部系统的交互。`config`目录包含了应用程序的配置文件。`domain`目录包含了应用程序的业务逻辑,包括实体、仓储和服务层。`main.go`文件是应用程序的入口文件,用于启动应用程序。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值