3

六边形架构的流程

我已经阅读了 Alistair Cockburn 提出的关于端口和适配器架构的不同来源，发现它适合我开发网关服务应用程序的场景，该应用程序从多个源接收消息并处理消息并将消息发送到多个目的地。这是我的详细实现。

  • 目前消息的来源是单一的（JMS Queue）
  • JMS 端口订阅 JMS 消息队列并将其传递给 JMS 适配器，后者又调用相应的消息处理程序。
  • 消息处理程序依次调用与cockburn 建议的消息源或目标无关的业务域层。
  • 由依赖注入容器注入的具有JMS Port、WCF Port、DB Port、TCP Port的消息处理程序依次调用JMS Port、TCP Port和WCF Port来发布/发送域处理的消息。

如果我是否偏离了 Cockburn 提出的架构，我有几个关键问题/疑问。

  1. 单个端口能否同时处理消息的流入/流出（在本例中为 JMS 端口）。或者为消息的流入和流出设置单独的端口是一种好习惯。

2.根据 cockburn 的文章，它说

入站通信：“当事件从外部世界到达端口时，特定于技术的适配器将其转换为可用的过程调用或消息并将其传递给应用程序。”

出站通信：“当应用程序有东西要发送时，它会通过端口将其发送到适配器，适配器会创建接收技术（人工或自动）所需的适当信号。”

因此，我已将处理后的消息直接传递到端口，该端口又调用适配器根据目标要求转换消息。

  1. 消息处理程序（应用层）可以依赖注入的端口吗？

  2. 根据 Cockburn 的文章，它说

任何一个端口通常都有多个适配器，用于可能插入该端口的各种技术。

我想不出单个端口需要多个适配器的情况。你能给我一个场景，这样我就可以充分利用架构。

4

1 回答 1

2

以下是我的观点：

  1. 是的，一个端口可以同时进行流入和流出操作。对我来说，这取决于六边形实现的用例以及它使用该端口的原因。例如，我可以想到一个端口“IPersistenceGateway”，它具有像“GetUsers”和“SaveUser”这样的读写方法。该端口代表所有六边形的持久性抽象；在其他情况下，我可以使用“IReadingPersistenceGateway”和“IWritingPersistenceGateway”，将上述两个操作拆分为，以便将读/写操作“à la CQRS”分开。

  2. 我认为您的“应用程序层”应该被视为“在六边形内部”：所以是的，消息处理程序可以依赖注入的端口。我认为消息处理程序应该是从六边形外部可见的唯一对象，因此是第一个获得端口的对象，由外部注入。

  3. 在我上面提到的示例中，端口是“IPersistenceGateway”，对于 MySql 和 MongoDb 上下文，可能有一个“MySqlPersistenceGateway”和一个“MongoPersistenceGateway”来管理六边形的抽象持久性需求。

在您的情况下，据我了解，我认为 JMS 适配器可能已经注入了六边形的消息处理程序，因为 JMS 适配器必须将消息“推送”到六边形而不是反之亦然（从适配器）。如果这是正确的，那么（在我看来）拥有一个直接引用六边形内的消息处理程序的适配器是没有问题的。重点永远是依赖的方向：永远朝着抽象，从外六边形到内（DIP，Dependency Inversion Principle）。

于 2015-04-08T07:10:14.703 回答