带存储库的六边形架构
这对我来说是棘手的部分。我想实现UserRepository的逻辑，但对我来说，在应用程序层实现这一点没有意义，因为持久性上下文在基础结构层（例如JDBCUserRepository或JPAUserRepository)。但是，如果我正确理解六边形结构，我就不能直接在基础结构层实现userrepository接口，因为基础结构层不应该知道域层。
我错过了什么？
共有1个答案
我想知道完全相同的问题，下面是我的结论：您正在讨论的实现是由适配器处理的。
您已经将业务层开发为六边形。嗯！这意味着，您的实现依赖于一个向外部公开的协定(=API接口）。同样，您的实现使用其他接口来与外部通信(=称为UserRepository的SPI接口）。多亏了这些接口，你的六边形与外部隔离。当您的六边形将被实例化时，您的SPI的实际实现应该作为参数传递（控制的反转）。
现在，在您的底层，您将通过实现适配器（适配器模式）来实现您的Jpa逻辑。
-
我正在将nTier架构迁移到六边形架构中。我的域现在定义得很好，我有所有基础设施依赖项的接口。查看数据库存储库，我有几个数据库，在下面的一侧有一个类实现每个repo。我的问题是关于数据库依赖项的正确方法是什么： 1-在域端有一个接口来处理数据访问，然后依赖于基础设施实现，并有一个类作为所有数据库存储库的入口点，就像一个facade，从那里调用所有存储库实现。这种方法与我在nTier应用程序中已经使
-
并访问如下所示的坐标： 目前看来，这似乎很好，但我确信以这种方式存储地图肯定有一些缺点。如果有任何缺点，你能指出他们，也许提出一个更好的方式来存储地图？非常感谢您抽出时间。
-
服务->逻辑所在的位置（接口及其实现）。 实体->它们将在整个应用程序中使用。 Repository->基础结构层必须实现的接口。 基础结构层实现了存储库接口、JPA实体、对数据库的调用（hibernate）以及一些将JPA实体转换为核心实体的函数（映射器？）。 Spring data有一种非常有用的实现CRUD操作的方法： 但是，我认为如果我使用spring数据，如果UserRepository
-
我被一个似乎很容易解决的问题所困扰，但我似乎找不出正确的公式。 我有一个立方体坐标系中六边形群的列表。我知道群的立方体坐标，但我需要计算给定群中一个小六边形的“全局”坐标。 例如，在下图中，我知道和的坐标。如果每个组都有相同的半径（在本例中半径为1)，并且它们之间不重叠（让我们把它看作是从0、0、0开始的组的平铺，从而创建一个十六进制网格），那么我如何计算GroupB中心平铺的坐标呢？ 任何帮助都
-
我读了很多关于六边形体系结构的书，但是在我看到的所有例子中，所有的文件夹和类ubication都是不同的，这对我来说有点困惑。 我用下面的文件夹结构做了一个简单的Spring Boot应用程序。适配器文件夹包含存储库接口和rest控制器的实现。 在domain文件夹中，我有model，它是一个简单的POJO，ports，它是服务类的接口，包含了产品的所有业务逻辑，还有repository的接口，它
-
本文向大家介绍用css画一个五边形和一个六边形相关面试题，主要包含被问及用css画一个五边形和一个六边形时的应答技巧和注意事项，需要的朋友参考一下 还有 svg 转 base64 作背景图。 当然，点击范围可能会不符合需求。 另外提一句，clip-path 边框要另做，元素选择的背景图要另做，两种都不好做圆角。