Architecture 清洁体系结构图

下面是Bobs叔叔的经典干净架构图

我很困惑为什么网关比用例更外向。到目前为止，我所看到的所有这些图中都存在这种情况，包括网关或其他形式的数据访问机制

我理解用例不应该绑定到数据访问机制的细节，因为它们应该隐藏在架构边界之后。同时，构成此边界的服务的唯一用户应该是用例。这与图表有很大的冲突，因为遵循可视化规则，用例不能使用网关（尽管它们需要），框架工作的东西可以使用它们（尽管它不应该）

我错过什么了吗？如果没有，是否有更正确的方法来直观地表示干净体系结构的规则

我这样问是因为我正在创建一个图表，显示干净的体系结构+DDD绑定的上下文

我不满意DB和服务位是如何在用例圈之外的，因为不清楚用例是有界上下文的公共接口，并且持久性不能从外部直接访问

类似的东西解决了这两个问题，但引入了一个新问题：没有数据访问层边界的指示。事实上，根据可视化规则，该图表明，有界上下文中的所有内容都可以直接访问持久性

---

我相信我遇到了同样的问题，导致网关在原始图中“错位”，我正在寻找解决方法。

该图是Alistair Cockburn的更精细版本，它在适配器的使用方面更加精确，尤其是在CDI方面

本质上，其思想是将依赖性向内转换：用例可能依赖于实体（即，导入域相关包和使用域数据类型；Cockburn没有将它们描述为单独的圆圈，而是将其描述为“应用程序”）。左边的适配器可以调用用例（即，执行或中止它们，例如使用命令模式），而用例反过来可以调用接口（例如，服务或存储库外观，由右边的适配器实现），使用依赖项反转原理来保留入站方向

如果您对“左”和“右”感到困惑：在Cockburn的图片中，hexagon在左侧（输入/交互机制）和右侧（持久性、外部系统、服务）有适配器。您可以将其视为一个三层体系结构图，其角度为90度，其中域层不依赖于持久层，而是相反

---

同样，Cockburn的解释，虽然由于不寻常的六边形图像，可能有点难以理解，但更精确，因为它没有试图包括所有内容，而是集中于依赖性的基本原理

在BC图形中，UC外缺少一个环绕的圆。这一圈是基础结构，您应该在其中放置域模型的存储库接口的存储库实现。实现使用一种技术（例如SQL）访问数据库

所以圆圈是从内到外的：

• 域模型（实体、值对象、存储库（接口）等）
• 应用层（用例）
• 基础架构（UI、存储库（实现）等）

依赖关系指向内部，而不仅仅是内部的下一个圆圈（基础结构取决于应用层和域模型）

---

不过我使用的是六边形架构。

该图显示了实现所在的位置，而不是接口。网关接口与用例一起驻留

网关接口必须位于用例层，并在接口适配器层中实现，以确保依赖性规则

  Interface Adapters Layer    || Use Cases Layer
                              ||
  +-----------------+         || <implements>    +-------------+   <uses>  +---------+
  |JDBCEntityGateway| --------++-------------->  +EntityGateway|  <------  | UseCase |
  +-----------------+         ||                 +-------------+           +---------+
                              ||

接口适配器层| |用例层
||
+-----------------+         ||     +-------------+     +---------+
|JDBCEntityGateway-->++-->+EntityGateway--您能否解释一下，对于不是服务器端web应用程序的应用程序，它有什么不足之处？（或链接到解释）回答以下问题：1）在高度分布式的系统中，信息流通常是多向的，需要在所描述的圈子中“跳进跳出”。可能会有互动者或演讲者参与，但不一定要有。系统中通常还有一方包含只读服务和视图（读取模型），并且状态是根据事件（重新）计算的。当然，您会发现“干净的体系结构”中嵌入了一些原则，但实际情况会有所不同。2）在企业环境中，您在高度分区（通常是遗留系统）中拥有领域知识、演示者和视图逻辑，这些系统将覆盖一些信息流，但不能像“调用api的适配器”那样整齐地分开。同样，应用基本原则（例如，努力实现域分离和定义良好、界面清晰的反腐败层）也很好，但需要更细粒度的方法才能发挥作用。3）在单页应用程序和移动应用程序中，Martin方便地将其抽象为“设备”，您通常会有本地域逻辑和状态，这些逻辑和状态必须与此图中的web服务同步。有些交互可能看起来与描述的一样，但涉及到更复杂的数据流场景。再一次，基本原则是有用的，但是这个图描述的解决方案是不够的。我认为假设只有一种设计“干净架构”的真正方法是危险的，因此所有其他方法都必须是“不干净的”。对于不同的系统组件、不同的需求和不同的环境，将应用不同的规则。在一种情况下，谨慎的做法可能是