问题标签 [hexagonal-architecture]

我有机会重写我的雇主用于文档控制的内部开发应用程序的核心。我的“核心”需求清单是这样的：

• 更容易导入/导出为各种格式（文件集合 + 相当广泛的元数据是共同因素）
• 更容易在多个级别添加新字段（其存在是数据驱动的，而不是全局的）
• 引入几个违反旧系统基本前提的新功能（基本上，围绕文档的元数据结构正在发生根本性变化）
• 保持严格控制文档和元数据关系和约定的能力

我一直在尝试使用序列化作为与世界通信的主要方式的架构，到目前为止，我对结果很满意——我可以从用户界面、XML 存储和无需修改核心类以适应各种来源和接收器，即可轻松使用数据库。我认为这基本上是一个六边形架构- 它以相同的方式对待每个序列化目标（作为 Serialize 方法的可注入依赖项）。

然而，这是我第一次使用这种方法，我想知道是否有人对此有任何经验，如果有的话，有什么见解或建议。

我有一个序列化数据的类。我可能想将此数据序列化为 JSON 或 YAML。在这种情况下，我可以干净地将 YAML 换成 JSON 对象吗？我希望我能做类似下面的事情。这是白日梦吗？

我尝试在 Ruby 中设计一个基于 Web 的应用程序。我已经开发了一个简单的核心应用程序，在没有框架和数据库的情况下在六边形架构中实现 DCI 范例。核心六边形中有小六边形和网络、数据库、日志等适配器。每个六边形在没有数据库和框架的情况下自行运行。在这种方法中，如何提供与数据库模型和实体类的关系与数据库无关。我想将来将框架从 Rails 更改为 Sinatra 或数据库。实际上，如何在这个核心的Hexagon中实现完全隔离rails和mongodb的数据库适配器或框架适配器。有任何想法吗？

Alistair Cockburn 引入了六边形架构，现在称为端口和适配器模式。在我的理解中，这个概念类似于 n 层架构，其中一层仅通过抽象（接口）依赖于另一层。例如，应用层依赖于许多存储库服务接口，而不是它的实现。这里不需要单独实现端口或适配器。像 Unity 这样的 IoC 容器可以注入存储库的实现，因此不需要适配器。

我是否将此端口和适配器模式与 DIP（依赖注入原则）混淆了？

有人可以指出端口和适配器模式的实现吗？谢谢。

假设您有一个需要 2 个服务的应用程序，例如。Application, Service1,Service2

您是否应该按照这种洋葱架构构建额外的间接级别并将其中一个服务提升为应用程序服务，并将另一个降级为域服务。

或者你应该Application直接连接到两者Service1吗Service2？

通过另一个级别的间接，您可以减少对层的依赖Application，尤其是对外部服务，例如。'Paypal'、'Facebook'、'Cyber​​Source' 并创建更适合您的编程范式的应用程序服务适配器。毕竟，让所有开发人员熟悉所有这些广泛多样的 API 确实不利于生产力。Façade/Adapter 将使事情更容易开发，同时保护应用程序免受基础设施变化的影响。例如。该公司在 Cyber​​Source 上失败了，决定改用 Paypal，幸运的是，您的应用程序被屏蔽了，您只需要更改适配器即可。

也就是说，适配器肯定会造成不灵活。随着应用程序复杂性的增加，适配器也变得泄漏。那么您可能会遇到 3 个问题：泄漏抽象、惰性层（由于有太多孔而做得不够的层）以及违反通用闭包原则，因为任何时候您需要更改 UI，您不仅要修改您的应用程序，还有您的适配器。

当Service2已经是同一家公司的内部服务时会发生什么？你还应该为每个子系统创建一个适配器吗？如果你的团队很小怎么办？如果您拥有数十个拥有不同技术的团队怎么办？是否有关于添加另一层间接与直接调用服务的适当性指导？

在 Entity-Control-Boundary 模式中，边界类是何时创建和启动的，由哪个原型类创建和启动？

这个问题也可以等同于；在六边形架构中，谁负责创建主适配器？

谢谢迈克布朗

我昨天参加了一个关于扩展 Rails 的聚会，其中一个主题是 Hexagonal Rails。但是，我只做 Rails 一年，对 MVC 结构真的很舒服（也许太舒服了），所以我不太了解适配器和消息队列是什么。

这是一篇关于它的文章：http: //victorsavkin.com/post/42542190528/hexagonal-architecture-for-rails-developers

还有一张照片：http ://blog.mattwynne.net/wp-content/uploads/2012/06/hexagonal_architecture_sketch.jpg

据我了解，我认为这是关于解耦各个部分，以便专门过滤操作并将其传递到应用程序的某些位置，而不是为所有内容配备一个中央“路由器”。我认为这会最大限度地减少 ActiveRecord 的使用和大量模块的创建？我对此很困惑，所以我有几个问题：

1. 为了使我的项目成为 Hexagonal Rails 项目，我将这些模块放在哪里（什么文件夹？我是否创建一个具有特定名称的新文件夹？）

2. 这更多是为了内部维护吗？为了安全？

据我所知，如果 Rails 应用程序变得太大，您不能将某些部分拆分为另一个应用程序（我相信它称为面向服务的架构？）然后从您的主应用程序向它发出请求？或者，如果流量太重，也可以使用负载均衡器 + 多台服务器。

我了解如何使用实体框架来实现一个工作单元，并且仅在执行完整单元后才提交更改，但是我该如何更进一步呢？例如，以下需要全部发生在一个事务下

我不太确定如何确保发送电子邮件和将用户保存在数据库中都发生在一个事务中。任何意见是极大的赞赏

我一直在尝试理解这种新型架构，其名称可以是 Onion 架构、Clean 架构、端口和适配器等。

如果我采用端口和适配器的抽象，当我为特定端口调整我的应用程序时，我可以从我的应用程序内部给端口一个实体吗？还是我总是应该调整实体以适应端口？

例子：

假设我有一个客户实体。我有一个使用我的应用程序的 UI。我的 UI 通过适配器调用 getCustomerById(123)。反过来，我的适配器将调用我的应用程序，使用注入的存储库有效地检索客户，并将对其执行某种格式化和日志记录，一旦客户准备好，它就会返回到我的 UI。我的问题是，我的 Customer 对象按原样返回到我的 UI。这意味着我的 UI 引用了我的 Core 项目中的 Customer 类。然后我的 UI 继续使用该客户对象来做事，可能会更改它的名称等，并最终再次调用适配器来更新客户（客户）。

这可以吗？我的 UI 可以在我的应用程序核心内部使用 Customer 类吗？或者我应该改为让我的客户适应一个新的客户对象，比如 UICustomer 并让我的 UI 使用它，在适配器级别在客户和 UICustomer 之间来回映射？

在阅读了有关端口和适配器架构的不同来源（包括 Alistair Cockburn 的原始文章）之后，我仍然不确定术语“端口”和“适配器”的明确含义——尤其是在将这些概念映射到实现工件时。

一些消息来源（例如这篇文章）暗示这种架构模式中的端口是最外部的工件，然后是中间层中的适配器，它们在端口和核心应用程序之间进行转换。

然而，在 Cockburn 的原始文章中，端口出现在适配器层的外部和内部，具体取决于通信方向：

• 入站通信：“当事件从外部世界到达端口时，特定于技术的适配器将其转换为可用的过程调用或消息，并将其传递给应用程序。 ”
• 出站通信：“当应用程序有东西要发送时，它会通过端口将其发送到适配器，适配器会创建接收技术（人工或自动）所需的适当信号。 ”

实际上，对我来说，“所有外部”方法和“内部和外部”方法都没有意义 - 我将端口视为始终放置在应用程序旁边的工件，无论通信方向如何。Imo 这也与端口和适配器的隐喻一致：例如。有一个带串口的设备，要将另一个没有串口的设备连接到这个设备上，我需要一个适配器，从我的设备的角度来适应入站和出站通信。

谈到这个架构的实现，我会看到端口的定义，而不是我的应用程序的一部分，我会看到不同的适配器在我的应用程序“外部”。例如。单个端口的实现可以由一个facade（由适配器调用以进行入站通信）和一个interface（由适配器实现以进行出站通信）组成。

术语端口和适配器的正确含义是什么？如何将这些概念映射到实现工件？

更新：

发现这篇文章与我的理解相似。问题仍然存在，是否存在某种共同协议。