问题标签 [hexagonal-architecture]

我有一个问题问你。

我有一个六边形架构的 .NetCore 项目。在我的存储库类中，我填写我的域类，它的名称是公司，并且有两个属性：Id 和 Logo。

我的存储库返回 de Id 和徽标名称，但不是所有 url 路径，所以我想设置 logo 属性，将我的图像路径 url 放在 de 名称之前，例如http://example.com/imageName.jpg。

所以我的问题是，在六边形架构中，设置此属性的最佳实践在哪里？

现在，在我的控制器中，我创建了一个 DataModel，它为构造函数传递了我的域类，并在模型内部构建了图像徽标 url。

那么，您认为这是最好的方法吗？

谢谢！

我一直在对 Hexagonal Architecture aka 端口和适配器进行大量研究。我喜欢这些概念，但在一些实用性上苦苦挣扎。例如，域不应该具有数据库访问详细信息（实现）。相反，它应该在框架层中。但是为了获取正确的数据，数据访问涉及很多“智能”，在我看来，这应该属于域吗？因此，我正在寻找一个示例 Java 项目，该项目实际上演示了域、应用程序和框架层之间的交互。有谁知道这样的事情是否存在？我没有多少运气找到它。很多关于六边形架构概念的博客，但没有具体的例子。

在遵循具有 ddd 原则的六边形架构时，用例或应用程序服务是否应该具有接口和实现？例如，用例“删除视频”，是否应该让 IDeteVideo（接口）和 DeletVideoImpl（实现）实现该接口？

如果答案是肯定的，用例的接口应该在哪里，在领域层还是在应用层？很明显，实现应该总是在应用层。

我认为用例不是经常变化的东西，所以在我看来，我认为没有必要有一个接口，有实现就足够了。但就六边形架构和 DDD 原则而言，是否对此进行了说明？

提前致谢。

我有一个Document类需要在保存到数据库之前进行外部授权。

可以创建一个authorize像...这样的方法吗？

然后在用例或服务中使用它...

还是我应该有这样的Document课......

然后用例......

还是没有，只有第三种选择？

有什么帮助吗？

你有Job*--1 ，所以在你的数据库中你的表中Board会有一个。board_idjobs

现在，在域中，Job可以没有Board. 因此，考虑向它添加boardId属性对我来说并不合乎逻辑。

可以通过 管理它BoardRepository吗？例如打电话给BoardRepository.addJob(Board board, Job job)？所以存储库会将作业映射到数据库对象，然后board_id在插入时添加字段？

问题是......如果我想通过查询作业/jobs/{id}，我需要boardId在域类中有属性，所以它不会映射到正确的 DTO。

希望我很清楚。

我需要知道一个实体（用户）是否匹配给定的某些条件。我已经在域中定义了标准，它们实现了一个接口：

现在的问题是一个标准需要另一个实体（公司）的数据，而用户只有公司 ID。

我应该如何处理？我可以在域（CompanyResolver）中创建一个接口并在标准中使用它吗？该接口将由存储库实现。

谢谢

我问你谁知道并且有使用任何分层架构（洋葱、六边形、干净等）构建软件的经验。每当我在谷歌上搜索软件架构时，人们都会有不同的观点，并以不同的方式解释相同的架构。

条款

在您阅读问题之前，有些术语可能会让您感到困惑，因此我在下面对其进行定义。我不确定我是否对它们有“正确”的定义，但我从互联网上收集了这些信息。如果我有误解，请告诉我。

领域层：包含企业/业务逻辑并使用领域模型。位于中心，不依赖于域模型以外的任何其他层。

应用层：包含应用逻辑，接受来自基础设施层的DTO，传递View Model

DTO（Data Transfer Object）：一个类，JSON字符串等，用于在层之间传输数据。可能是纯数据容器。

VM（视图模型）：从应用层传递到表示层的 DTO。

DO（Domain Model）：领域层使用的类、JSON字符串等。可能是纯数据容器。

VO（值对象）：数据库实体（数据库行），或数据库使用的数据格式。可以从数据库层转移到应用层。

概括

在洋葱、六边形或干净架构中，域层位于中心（即域层不依赖于域模型以外的任何层，域模型用于将数据传输到其他层或接受来自更高层的数据）。

这意味着域使用的域模型（DTO、POJO、VO 或其他）可能与数据库用于保存持久数据的模型不同。

我画了一张图，以便给你更好的解释。

Q1：

请看第二张图片的红色部分。

如果领域层在中心，不像传统的分层或n层架构，领域模型能否比数据库实体（行）拥有更多的属性（或不同的属性）？

例如，假设域层使用一个名为Person的类。用户请求在服务器中注册的所有人的照片。让我们假设数据库只包含所有人的姓名。但是，我们可能会使用其他网络服务器通过姓名请求人的照片。所以应用层会从数据库中读取所有的名字，通过这些名字，它会通过一个HTTP请求从其他web服务器获取所有的图片。之后，带有名称和图片的Person列表将作为视图模型 (DTO) 发送给用户。

Q2：

持久层可能由数据库、文件系统、其他 Web API 等组成。

表示层可能是网站、桌面应用程序、移动应用程序、Web API 等。

这两层都是基础设施层的一部分，依赖于应用层，但应用层只依赖于领域层。

当应用层在接受来自表现层的请求时，没有问题，因为表现层调用应用层并且表现层知道应用层。

大多数时候，应用层需要从持久层获取数据。

应用层不可能在没有任何依赖的情况下调用持久层，因为它不知道持久层中的任何类。

到目前为止我的理解是这样的，有人可以给我一个清楚的解释数据应该如何流动以及如何从较低层到较高层进行通信吗？

对于那些想写代码的人，我更喜欢 C#。

我已经阅读了 Alistair 关于 Hexagonal 模式的文章并浏览了与此相关的其他资源（Alistair 的视频、端口和适配器的简短描述）。

我了解六边形架构的总体概念以及它为现代应用程序开发带来的优势。但是，我仍然对端口和适配器的实际实现有些困惑。

问题一：

从 Alistair 的文章中，

在一个实现中，端口和适配器以两种方式出现，我将它们称为primary和secondary，原因很明显。它们也可以称为驱动适配器和从动适配器。

他将端口分为驱动端口和驱动端口两类。驱动端口控制应用程序（GUI）和驱动端口由应用程序（数据库）控制。

因此，如果驱动端口应该只包含控制 API，那么驱动端口侧的适配器将如何获取事件通知。例如，在下图中，我有两个驱动适配器来控制应用程序，但它还需要来自应用程序的信息才能将其发送回连接到该适配器的其他应用程序。

您可以将其statusInfoEvent()视为从应用程序端发出的 Qt 信号或一些常见的可观察模式。 将传入和传出流量 API 保持在同一接口（端口）是否违反六边形模式？最重要的是，实现是在六边形内部完成的，因为它是一个驱动端口。

问题2：

曾经见过或研究过如下的六边形图案。

将服务 1 的驱动适配器视为某种存储介质，服务 1 可以向/从其推送信息。服务 1 的这两个适配器（驱动和驱动）在服务 2 内部实现（至少在项目级别），现在服务 2 从它的驱动适配器（web 或 dbus）接收一些数据并更新服务 1 驱动适配器的存储介质，还需要通过驱动适配器通知服务1的更新。

是否有可能以更好的方式做到这一点？

我创建了一个基于 DDD 和六边形架构以及 CQRS（没有 ES）的应用程序。

我被困住了。

在有界上下文之一中，我有层：

• 领域，
• 应用，
• 基础设施，
• ui。

我认为这是一个相当普遍的解决方案。

目前，应用程序的任何元素都没有超出其层。我相信我根据所有建议明智地分配了所有内容。

因此，我不打算在这里描述给定层中包含的内容。

但是，我很难为某些元素找到合适的位置。

那么如何处理生成 slug 和 UUID 的类呢？

也许我知道的太少，但根据收集到的知识，我在上面的任何层中都看不到它们的位置。另外，我不想创建类似“共享”或“通用”层的东西。目前，我停止了在应用程序中为它们创建接口的解决方案，并将实现留给基础设施。

另一件困扰我的事情：我有警报实体。它负责在系统中显示通知。其中一些是根据类别随机生成的。当我使用 CQRS 时，通知生成器不是从域中获取警报，而是作为查询模型获取警报。

那么哪一层适合这样的生成器呢？这样的发电机可以被视为一种服务吗？

我指望帮助。

最近我在学习 DDD。我也有一些六边形架构（也称为ports and adapters）的经验。我想将我的想法付诸实践并创建一个交易应用程序。起初我不想拥有一个monolithic具有一些基本功能的应用程序。我有组合DDD和微服务以及端口和适配器以及 MVC 的经验，但我目前面临的挑战对我来说是新的。

因此，以下是该应用程序预期的一些功能：

• 监控和保存价格/数量
• 按照策略执行自动交易
• 回测策略
• 为交易者创建交易历史和交易日志

当然还有一些其他的东西，比如身份验证。数据库和 web ui 等服务也确实存在。

所以我的第一个问题是什么bounded context？是什么sub domains？例如，用户想要查看实时价格数据，并且在后台，应用程序会以持久的方式保存这些数据，而不管用户是否正在检查价格！现在由于两个功能共享很多，它们是相同bounded context的还是相同的subdomain？

我遇到的下一个问题是打包应用程序。看了很多文章还是想不通我怎么能DDD和Onion风格结合起来hexagonal。我正在使用golang，但我认为整体结构应该是相同的跨语言。我想出了这样一个结构：

很明显，这里缺少很多东西，我不知道在哪里放置repositories,DTO's和Event bus许多其他对象。此外，我不确定这种结构，因为我已经看到一些实现将目录相互嵌套，就像洋葱一样！现在我不想拥有多个模块和二进制文件，但是应用程序有可能增长到多个微服务，如果发生这种情况我不想处理heavy refactoring（可能永远不会发生，只是作为现实世界的实践，我想它可能会发生）。

我很困惑，我的一些指导可以帮助我很多。谢谢