六边形架构中的层答案

【问题标题】：Layers in Hexagonal Architecture六边形架构中的层
【发布时间】：2021-04-06 15:33:40
【问题描述】：

我阅读了很多关于六边形架构的文章，但是在我正在查看的所有示例中，所有文件夹和类 ubication 都不同，这让我看起来有点困惑。

我已经完成了一个简单的 Spring Boot 应用程序，其文件夹结构如下。适配器文件夹包含存储库接口和其余控制器的实现。

在域文件夹中，我有模型，它是一个简单的 POJO，端口，它是服务类的接口，包含 Product 的所有业务逻辑，以及存储库的接口，它公开要在存储库中实现的方法。

在另一个文件夹中，我有服务实现，正如我之前所说，产品的业务逻辑。

这是为简单用例实现六边形架构的正确方法吗？如果不是，为什么？我应该把每节课放在哪里，为什么？这是不清楚的……

非常感谢！

【问题讨论】：

六边形架构更多的是关于实现之间的关系，而不是关于源文件/文件夹的组织。

标签： spring-boot architecture domain-driven-design clean-architecture hexagonal-architecture

【解决方案1】：

您可以随意组织代码。这与六边形架构无关。

话虽如此，如果您想有效地使用六边形架构，您可能应该遵循领域驱动设计，也就是说，您应该根据领域/业务逻辑组织代码，而不是基于技术相似性.

例如，而不是具有以下结构：

controller
    product
    cart
    customer
service
    product
    cart
    customer
repository
    product
    cart
    customer

DDD 推荐如下结构：

product
    controller
    service
    repository
cart
    controller
    service
    repository
customer
    controller
    service
    repository

完成此操作后，如果有帮助，您可以将它们封装在三个包中，用于六边形架构的不同部分：用户端、业务逻辑和服务器端。这是我过去做过的事情；它可以帮助我保持不同的层次清晰。

userside
    product
        controller
    cart
        controller
    customer
        controller
businesslogic
    product
        service
    cart
        service
    customer
        service
serverside
    product
        service
    cart
        repository
    customer
        repository

同样，包的结构并不是最重要的概念。六边形架构侧重于三个原则：

明确分离用户端、业务逻辑和服务器端层。清晰的包结构会有所帮助，但您可以通过其他方式分隔这些层。
依赖关系从用户端和服务器端层到业务逻辑。这是通过在业务逻辑中定义接口和适配器来完成的（见下文）。目标是可以在不影响业务逻辑层的情况下更改用户端和服务器端的代码。例如，如果您希望将存储库从 MySQL 实现更改为 PostgreSQL 实现（在服务器端层），此更改不应影响您的业务逻辑：新实现只需要符合业务逻辑中的接口。
依赖注入：业务逻辑定义接口（通常称为“端口”）和转换器（“适配器”），用户端和服务器端层必须遵守这些接口才能进行通信。

这是一个非常面向 DDD 的架构；这个想法是业务逻辑尽可能接近领域，并且不受技术要求的影响。

【讨论】：

谢谢！非常清楚！这就是我要找的东西！

【解决方案2】：

六边形架构并没有说明如何组织六边形代码（业务逻辑）。您可以随心所欲地实施。

看看这些文章：

https://jmgarridopaz.github.io/content/articles.html

【讨论】：