Design patterns 用于Windows服务的六边形体系结构/端口和适配器体系结构。对吗？

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

• 当前消息源是单一的（JMS队列）
• JMS端口订阅JMS消息队列并将其传递给JMS适配器，后者反过来调用相应的消息处理程序
• 消息处理程序依次调用业务域层，该层独立于cockburn建议的消息源或目的地
• 由依赖项注入容器注入JMS端口、WCF端口、DB端口、TCP端口的消息处理程序依次调用JMS端口、TCP端口和WCF端口来发布/发送域处理的消息

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

单个端口能否同时处理消息的流入/流出（在本例中为JMS端口）。或者，为消息的流入和流出提供单独的端口是一种好的做法

2.根据cockburn的文章，它说

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

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

因此，我将处理后的消息直接传递到端口，该端口反过来调用适配器，以根据目标需求转换消息

消息处理程序（应用程序层）是否可以注入端口的依赖关系

根据Cockburn的文章，它说

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

---

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

以下是我的观点：

是的，一个港口可以有流入和流出操作。对我来说，这取决于hexagon实现的用例以及它使用该端口的原因。 e、 我可以想到一个端口“IPersistenceGateway”，它有像“GetUsers”和“SaveUser”这样的读写方法。该端口表示所有hexagon的持久性抽象；在其他情况下，我可以使用“IReadingPersistenceGateway”和“IWritingPersistenceGateway”，将上面提到的两个操作拆分为，以分离读/写操作“a la cqr”

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

在我上面提到的示例中，如果端口为“IPersistenceGateway”，则可能有一个“mysqlpersistenceGateway”和一个“MongoPersistenceGateway”，用于管理hexagon对MySql和MongoDb上下文的ASB抽象持久性需求

在您的情况下，据我所知，我认为JMS适配器可以注入hexagon的消息处理程序，因为JMS适配器必须将消息“推”到hexagon，而不是相反（从适配器中提取消息的xexagon）。如果这是正确的，那么（在我看来）在hexagon中有一个直接引用消息处理程序的适配器是没有问题的。点始终是依赖的方向：始终朝向抽象，从六边形的外侧到内侧（DIP，依赖反转原理）