六边形架构中的数据库存储库依赖项

Question

我正在将 nTier 架构迁移到六边形架构。 我的域现在定义良好，并且我拥有所有基础设施依赖项的接口。 查看数据库存储库，我有几个数据库，并且在 Infra 端有一个实现每个 repo 的类。 我的问题是关于数据库依赖的正确方法应该是什么：

1- 在域端有一个接口来处理数据访问，然后依赖于基础设施实现，并有一个类作为所有数据库存储库的入口点，就像一个门面，从那里调用所有存储库实现。这种方法与我在 nTier 应用程序中已有的方法相同，外观和存储库是当前的数据库层。

2- 在域端为我需要的每个数据库提供接口。每个接口都将在 Infra 端实现以访问相应的 DB。它使层保持薄，但这种方法将数据管理逻辑添加到域。域不应该关心数据在哪里，基础设施应该处理这个问题。如果将某些数据移动到另一个数据库，则需要在 Domain 端更改相应的接口（例如，将暴露该数据的方法移动到另一个接口）

告诉我，

Answer 1

这是个好问题。我在一个应用程序中遇到了同样的困境，我决定选择您公开的第一个选项：

只有一个端口用于访问数据，域不关心数据的来源，无论数据存储在哪个数据库。在适配器中，我有一个外观来将请求转发到正确的数据库。事实上，就我而言，结果数据可能来自两个数据库。

但我认为另一个选项也是有效的，如果我们将数据库视为我们的应用程序必须与之通信的外部系统。我们的应用必须知道必须与哪些次要参与者进行通信，在这种情况下，每个参与者都会在域中拥有一个端口。

无论如何，我认为第一个选项更“正确”，因为六边形架构中的端口是通信的目的，在这种情况下是“检索数据”的目的。在这次谈话中，Alistair Cockburn 解释了这一点。他说港口必须按照他们的意图命名，说明他们的用途。端口是为了……做某事。

谈谈“六边形中的阿利斯泰尔”：

https://www.youtube.com/watch?v=th4AgBcrEHA

https://www.youtube.com/watch?v=iALcE8BPs94

https://www.youtube.com/watch?v=DAe0Bmcyt-4