问我真的分不清六角形建筑和分层建筑的区别

EN

关键的区别在于依赖关系管理：

分层体系结构的目的是通过堆叠层来减少依赖:一个层中的每个组件都可能依赖于下面层的组件(原则上，就在下面，尽管可以绕过“开放层”)。有许多变体，但例如：

                             dependency
Presentation (UI)                |
Services                         |
Data access layer (DAL)          |
Database                         V 

六角形建筑 (以及随后的Onion或Clean )使用依赖反转。在这种架构中，外部核心只能依赖于内部核心。但是依赖反转用于允许内部核使用抽象的可互换接口，而不知道它们的具体实现。

                                      dependency  dependency inversion
Interfaces (to DB, with user, ...)        |        <--+
Services                                  |           |
Business logic                            |           |
Entities                                  V        ---+

当层/核表示系统中的内部分解时，六边形方法允许您在中心有更多的抽象元素，并在抽象基础上构建具体的类，而层需要依赖于具体的实现。

更多的想法：

• 当层变成层(即可以在不同服务器上运行的可部署组件)时，仔细的API设计可能会使每个层之间的抽象充分解耦，从而使差别不那么明显。
• 层更难水平拆分，而在六边形方法中，很容易依赖抽象，其实现通过端口和连接器外包到另一个六边形(即微服务架构背后的想法)。

它可能令人困惑，分层体系结构是如此通用的术语。现在，任何东西都是分层结构。差异是每个层所做的以及它们如何相互依赖。

(遗留)分层体系结构或三层结构由层组成。底层是数据库/persistence层，其中数据被持久化。最上面的是业务层，所有有趣的域逻辑都在这里发生。最上面的是表示层。需要注意的最重要的事情是，业务层依赖于持久层。这意味着，在使用业务对象时也不能拖放持久性。通常以数据库的形式出现。

六边形六边形、打扫和洋葱体系结构也有层。但是，这些体系结构与(遗留的)分层体系结构之间的区别在于，它将业务域置于底层/中心。这意味着业务模型和域实体独立于它们的持久性。这对测试非常有帮助，因为您不需要费心地拆分数据库。并且不知道持久性，所以您可以使用SQL、NoSQL等.而且，您的域实体不应该关心您所使用的数据库。

分层通常是这样的(箭头表示依赖项)：

Data <-- UI

更多的分裂会变成：

Data <-- Logic <-- UI

六角体使用依赖反转来实现：

Data --> Logic <-- UI

并进一步：

 Database -->  |-------|  <-- CLI
Resources -->  | Logic |  <-- Desktop GUI
    Files -->  |-------|  <-- Web UI

左边的模块称为“驱动”，只需响应请求。右边的模块称为“驱动程序”，是生成请求的地方。一切都要经过逻辑，这是系统的业务规则，用纯无依赖的代码编写。逻辑成为系统的语言，任何部分都可以用来与其他部分进行通信。

这听起来很棒，而且确实如此，尽管实现起来可能比这听起来要复杂一些。但与此同时，我发现每件事都倾向于就位，一切事物都有一个清晰的地方可住。

在Data <-- Logic <-- UI设置中，我发现“逻辑”中的代码在任何地方都没有意义。它可能会出现在这三个地方中的任何一个，但仍然感觉不对。这是因为它仍然是真正的数据库代码，而且由于UI知道数据库，所以数据库代码仍然可以在UI中运行。或者可以进入数据层。也可以进入“逻辑”层。

对于六角形，所有依赖被过滤出你的逻辑，就像一个筛子，只剩下原始的无依赖的逻辑代码。现在，您希望尽可能多地将代码放在逻辑模块中，因为只要将代码放在其中，就可以删除它的依赖项，并使其更加可重用。