我想知道六边形架构如何与微服务相关联。微服务是否都进入了六边形的核心？还是每个微服务都有一个六边形架构？还是两者兼有（分形）？

我总是听说六边形架构必须与任何框架无关，并使用接口 (SPI) 来委派不属于业务层的代码的每个部分。

但是如何在不使用额外框架的情况下通过六边形架构创建反应式业务层？大多数时候 SPI 的实现将是响应式的（API 的实现/适配也是），业务层的核心也应该是响应式的。

是否有任何 JSR（由每个响应式框架实现）可以使用？或者我应该定义我自己的并使用我将在下一部分中使用的最终框架进行调整？

我有一个项目，我在其中使用了一些域模型。这些模型的 ID 是确定性的，仅取决于对象的内容。两个属性相同的对象将具有相同的 ID。这适用于我模型的任何对象。

这种计算是递归的，这意味着它会遍历引用并将它们自己的 ID 合并到计算中。它基本上是一棵默克尔树。

例如，如果我有一个 A 类和 B 类，如下所示：

然后我将计算 RefToB 的 ID，然后将所有内容序列化为字节，然后计算该字节数组的 SHA1，以获得另一个字节数组，这将是我的最终 ID。

我将使用计算的 SHA1 将对象的字节存储到专门为我的目的而定制的 KeyValue 存储中。

这使我可以很容易地比较子树。

现在，我不想添加构建无效模型对象的可能性，因此我不能将byte[] id参数添加到构造函数中，因为它是计算值。

我使用 DTO <=> 模型映射，我的商店使用 DTO 来计算 ID 并存储数据。

我尝试坚持六边形架构，这意味着我有一个持久性项目和一个域模型项目，域没有依赖关系。

问题是：我觉得我做错了设计，但我无法很好地解释我的错误行为。你认为我应该以不同的方式做这个设计吗？

我正在研究将端口和适配器模式与分层架构一起使用。

所以我将有以下几层：

• 框架/基础架构 - 即 ASP.NET MVC、实体框架、SMTP 客户端
• 应用程序 - 将您的应用程序拉到一起并在您的域上执行操作的逻辑。
• 域 - 定义域中的操作如何工作。定义域对象之间的关系

在阅读了https://softwarecampament.wordpress.com/portsadapters/#tc2-3、https://fideloper.com/hexagonal-architecture和其他几篇文章以及多个 youtube 讲座后，我仍在努力解决如何实现驱动程序端口和适配器。我理解驱动端口和适配器的想法，因为这是我使用普通分层架构所做的事情。

但我仍然不明白如何实现驱动程序端口和适配器。

据我了解，驱动程序端口定义了它外部的层应该使用它所在的层的方式。适配器是该端口在使用该端口的层上的实现。

但是我正在努力解决一些问题......应用程序层如何实现与域层的接口？那不是要求应用层知道领域层的相互作用吗？这完全破坏了首先使用界面的意义。如果领域层提供了一个外部的东西应该使用的接口，并且该接口的适配器是由使用该接口的层实现的，这意味着该接口的用户也在实现该接口本身。就像外部层告诉内部层如何工作......这违背了解耦甚至一般接口的本质。

听起来业务层正在告诉应用层，“这是我提供给你的接口...... IDK 它将如何工作，所以你告诉我。” 但是，为什么一开始还要有界面呢？

这是一些代码来演示我正在描绘的内容：

applicationLayer.UserRegisteringUseCasePort

frameworkLayer.UserRegisteringUseCaseAdapter

对我来说，这似乎很糟糕，因为现在您已经强制框架层进行验证，这应该是域逻辑的一部分（因为我们停在应用程序层，甚至没有机会这样做）。这也意味着应用程序层实际上并没有将业务逻辑拉在一起......它只是说明它想要完成的操作，但让调用者决定如何做。应该反过来吧？

概括

我知道我说了很多，所以让我总结一下……驱动程序端口和适配器如何工作？在现实世界的场景中应该如何使用/实施它们？

给定一个ReceiptValidator接口和一个返回多个数据的GoogleReceiptValidator实现，我应该把ReceiptValidatorResult放在哪里？

由于它与ReceiptValidator相关，因此可以放在域层中。

但是，如果另一个AppleReceiptValidator有不同的数据怎么办？ReceiptValidatorResult也应该是一个接口吗？

我有一个具有和字段的Subscription实体。statuscanceledAt

我想status从过期时间更改active为。canceledcanceledAt

所以，我想在方法中检查 cancelledAt Subscription::getStatus：

但这也需要更改持久层的状态。

我应该对事件做些什么吗？

我正在尝试研究如何在嵌入式软件系统的上下文中使用六边形（端口和适配器）架构。

如果我理解正确，架构是这样的。

让我们举一个具体的例子，其中一个用户界面是触摸屏，主控制器通过串行 UART 与之对话。该软件发送控制命令以在屏幕上绘制元素，并且用户操作会生成文本消息。

我看到在这种情况下工作的位是：

1. 串行驱动程序

   • 通过 UART 发送数据
   • 接收数据（调用 ISR）

2. 屏幕命令生成器

3. 屏幕响应/事件解析器
4. 业务逻辑，例如呈现和响应菜单、小部件等

我正在努力解决的问题是这些作品应该放在哪里。直觉上，我觉得是这样的：

• 基础设施- UART 驱动程序
• 领域- 业务逻辑
• 应用程序- 消息生成器/解析器

但是这种安排迫使应用程序和基础设施之间存在依赖关系，其中解析器需要检索数据，而构建器需要通过 UART 发送数据。

将消息构建器和解析器带入基础设施或域将整个用户交互从应用程序中移开。

无论我怎么看，它似乎都违反了我上面绘制的图表的某些方面。有什么建议么？

我正在应用程序中实现一个干净的架构。我有一个层，其中应用程序/用例类执行业务逻辑并与多个传出端口（用于数据库调用、http api 调用等的适配器的接口）交互。用例将值/模型返回给 Web 控制器（将输出呈现给应用程序的用户）。

由于业务逻辑的复杂性，有许多悲伤的路径和快乐的路径（它们是具有不同状态的不同类型的对象），以及可以冒泡到 Web 控制器的异常。异常由具有通用 http 响应的错误处理程序处理并记录。

为了返回快乐和悲伤的路径，我将它包装在两个字段的对象中。但我觉得这是一种代码味道，因为我总是有一个字段返回 null。因此，在 web 控制器/servlet 中，对填充字段进行检查以确定正确的 http 响应。这是这样做的好方法吗？

我见过用例，返回快乐的路径，所有悲伤的路径都被赋予了特定的业务异常。此异常在 Web 控制器/servlet 中被捕获，并使用异常消息创建 http 响应。我觉得这也是一种代码味道，因为我们在 Web 控制器/servlet 中使用异常作为控制流。

我见过其他返回多个值的方法，例如

• 使用元组
• 返回一个对象，但每个字段都是一个列表，因此无需将 null 作为空字段，并使用空列表
• 使用地图

是否有任何其他方法可以返回多个值，而不使用空字段或使用异常（如上所述）？

我正在寻找一些指导或最佳实践，以了解如何配置和构建符合同时支持多个（驱动程序）适配器的六角架构的应用程序。

我的 API/应用层/端口代表了应用的边界。我现在正在编写驱动程序适配器，目标是应用程序同时支持控制台/CLI 适配器和 REST 适配器。

有没有人对配置和连接应用程序的主要组件的方法有任何想法？

• 配置完整应用程序的单个主组件：包括所有主适配器。随着加载应用程序配置。在这种情况下，它将启动 REST 服务并启动 CLI 控制台应用程序。

• 每种类型的主适配器都有一个单独的主组件。IE。一个用于 REST 应用程序。一个用于 CLI / 控制台应用程序。我担心会导致在边界内配置应用程序的大量重复（即 API 服务、存储库等）。

• 遵循上述方法，但将通用配置/接线提取到共享类中。

如果有人有任何他们可以分享的例子，那将会很有趣。

干杯，

史蒂夫

您有一组微服务 A、B、C，由于各种原因与微服务 D 交互，有一天您发现有时需要通过加入 D 的一个 REST API 的一个输入字段进行潜在的清理或转换与其他一些信息。你基本上有两种选择：

1. 实现一个服务 E 并在调用 D 之前在 A,B,C 中编写与 E 交互的逻辑
2. 在 D 中实现一个专门的端口并在那里处理映射、清理和转换

第二种方法似乎更优越，因为它提供的重复更少并且更容易测试。有我们看不到的缺点吗？