我试图通过一个例子来理解六边形架构Repository。在这个设置中，我有以下几层：框架（基础设施）-> 应用程序-> 域。
我User在域部分，假设我想User通过DuplicateUsernameValidator. 为了获得这些信息，我需要从某个地方获得这些信息。我UserRepository在领域层又增加了一个接口，这样就可以在上面的层解决了。
这对我来说是棘手的部分。我想实现 的逻辑UserRepository，但对我来说，在应用层实现它没有意义，因为持久性上下文在基础设施层（例如JdbcUserRepository或JpaUserRepository）。但是如果我正确理解了六边形结构，我就不能UserRepository直接在我的基础设施层中实现接口，因为基础设施层不应该知道域层。
我错过了什么？
我认为您面临的困惑来自于您试图从六角架构的角度处理已经存在的三层应用程序这一事实。
让我们简单点。
让我们暂时忘记“应用层”是什么。
你有你的六边形，如果我理解正确的话，它包含你的应用程序的域（用户对象）。
正确地，您在六边形内定义了一个端口，允许您从其他地方检索用户。（我说的是UserRepository接口）
你的端口的所有实现（JdbcUserRepository或JpaUserRepository) 将代表您的端口的适配器，并且应该驻留在您的六边形之外，以便不将适配器的低级详细信息与您的六边形的高级策略耦合。
而已。
可能困难的部分是从具有三层架构（或某种......）的应用程序开始，了解必须进入六边形内部的内容和不应该进入的内容。
将与您的域完全相关且与基础设施无关的内容保留在六边形内。
移出一切都与外界有关，但不包含任何业务逻辑。
将具有上述两种上下文的所有内容分开并相应地移动。
我想知道完全相同的问题，这是我的结论：您正在谈论的实现是由适配器处理的。
您已将业务层开发为六边形。出色地！这意味着，您的实现取决于暴露给外部的合约（= API 接口）。同样，您的实现使用其他接口与外部通信（= 您称为 UserRepository 的 SPI 接口）。由于这些接口，您的六边形与外部隔离。当您的六边形将被实例化时，您的 SPI 的实际实现应该作为参数传递（控制反转）。
现在，在您的基础设施层中，您将通过实现适配器（适配器模式）来实现您的 Jpa 逻辑。
您的适配器（例如可以是 Spring 服务）将实现您的接口 UserRepository 并包装您的 JpaUserRepository。然后，您的 UserRepository 中的每个方法都将被重定向到您的 JpaUserRepository 的相应方法（有或没有一点调整）。
