六角形架构与存储库

Question

我试图通过Repository的例子来理解六边形架构。 在此设置中，我有以下层：框架（基础设施） - ＆gt;申请 - ＆gt;域。

我在域部分中有User，假设我想通过User验证DuplicateUsernameValidator是否有任何重复。为了获得这些信息，我需要从某个地方获取这些信息。我在域层中再次添加了一个接口UserRepository，这样就可以在上面的层中解决了。

这是对我来说很棘手的部分。我想实现UserRepository的逻辑，但对我来说，在应用层实现它是没有意义的，因为持久化上下文位于基础结构层（例如JdbcUserRepository或{{1 }}）。 但如果我正确理解六边形结构，我就无法直接在我的基础架构层中实现JpaUserRepository接口，因为基础架构层不应该知道域层。

我错过了什么？

Answer 1

我认为您所面临的困惑来自于您正试图从六角架构的角度来看待现有的三层应用程序。
让我们变得简单 让我们忘记它的“应用层”是什么时候 您有六边形，如果我理解正确，它包含您的应用程序的域（用户对象） 正确地说，您在六边形内部定义了一个端口，允许您从其他地方检索用户。 （我说的是UserRepository界面 您的端口（JdbcUserRepository或JpaUserRepository）的所有实现都将代表您的端口的适配器，并且应该位于您的六边形之外，以便不将适配器的低级细节耦合到六边形的更高级别策略。
就是这样。
可能困难的部分是要了解六边形内部的内容以及不是从具有三层体系结构（或某种......）的应用程序开始的内容。
保持六边形内部与您的域名完全相关且不与基础设施相关联 向外移动一切都与外部世界有关，但不包含任何业务逻辑。
分开并相应地移动它，所有具有上述两种情境的东西。

Answer 2

我想知道完全相同的问题，这是我的结论：你所谈论的实现是由适配器处理的。

您已将业务层开发为六边形。好！这意味着，您的实现取决于暴露给外部的合同（= API接口）。同样的想法，您的实现使用其他接口以便与外部通信（=您称为UserRepository的SPI接口）。由于这些接口，您的六边形与外界隔离。 当您的六边形将被实例化时，您的SPI的实际应用应作为参数传递（控制反转）。

现在，在您的infra层中，您将通过实现适配器（适配器模式）来实现您的Jpa逻辑。

您的适配器（例如，可以是Spring服务）将实现您的接口UserRepository并包装您的JpaUserRepository。然后，您的UserRepository中的每个方法都将重定向到您的JpaUserRepository的相应方法（有或没有一点适应）。