用于Windows服务的六角体系结构/端口和适配器体系结构。正确的方式？

Question

​

​

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

• 当前消息源是单一的(JMS队列)
• JMS端口订阅JMS消息队列并将其传递给JMS，后者反过来调用相应的消息处理程序。
• 消息处理程序反过来调用业务域层，该层是，与cockburn提出的消息的源或目的地无关。
• 由依赖注入容器注入的具有JMS端口、WCF端口、DB端口、TCP端口的消息处理程序依次调用JMS端口、TCP端口和WCF端口来发布/发送域处理消息。

我有几个关键的问题/怀疑，如果我是否偏离了科伯恩的建议建筑。

1. 单个端口能否同时处理消息的流入/流出(在本例中为JMS端口)。还是将消息的流入和流出的端口分开是一种良好的做法。

2.根据科克本的文章，它说

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

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

因此，我已经将处理过的消息直接传递给端口，而端口又调用适配器来根据目标需求转换消息。

1. 消息处理程序(应用层)可以注入端口的依赖性吗？
2. 根据科伯恩的文章，它说

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

我想不出一个端口需要多个适配器的情况。你能给我一个场景让我能充分利用架构吗？

Answer 1

以下是我的观点：

1. 是的，一个港口既可以有流入也可以有流出。对我来说，这取决于六边形实现的用例以及它使用该端口的原因。例如，我可以想到一个端口"IPersistenceGateway“，它有诸如"GetUsers”和"SaveUser“这样的读写方法。该端口代表了对所有六边形的持久性的抽象；在其他情况下，我可以使用"IReadingPersistenceGateway“和"IWritingPersistenceGateway”，将上面提到的两个操作分开，以便将“la CQRS”的读写操作分离开来。
2. 我认为您的“应用程序层”应该被认为是“六边形”：是的，消息处理程序可以具有注入端口的依赖关系。我认为消息处理程序应该是唯一从六边形外部可见的对象，因此也是获得端口的第一个对象，由外部注入。
3. 在前面提到的示例中，端口为"IPersistenceGateway"，其中可能有一个"MySqlPersisteceGateway“和一个"MongoPersistenceGateway”，用于管理MySql和MongoDb上下文中六边形的asbtracted持久性需求。

在您的示例中，我认为JMS适配器可以注入六边形的消息处理程序，因为JMS适配器必须将消息“推送”到六边形，而不是相反(将消息从适配器中提取出来的xex角)。如果这是正确的，那么有一个适配器直接引用六边形内的消息处理程序(在我看来)是没有问题的。重点始终是依赖的方向:总是面向抽象，从外部的六边形到内部(DIP，依赖反转原理)。