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

Question

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

• 目前消息来源是单一（JMS队列）
• JMS端口订阅JMS消息队列并将其传递给JMS适配器，后者又调用相应的消息处理程序。
• 消息处理程序依次调用业务域图层，该图层独立于消息的来源或目的地，如cockburn所提议。
• 具有JMS端口，WCF端口，数据库端口，依赖注入容器注入的TCP端口的消息处理程序依次调用JMS端口，TCP端口和WCF端口来发布/发送域处理的消息。

如果我偏离了Cockburn建议的架构，我有几个关键问题/怀疑。

1. 单个端口是否可以处理消息的流入/流出（在本例中为JMS端口）。或者，为信息的流入和流出设置单独的端口是一种很好的做法。

2.根据Cockburn的文章，它说

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

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

所以我已将已处理的消息直接传递给端口，而端口又调用适配器根据目标要求转换消息。

1. 消息处理程序（应用程序层）是否具有注入端口的依赖关系？

2. 根据Cockburn的文章，它说

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

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

Answer 1

以下是我的观点：

1. 是的，端口可以同时具有流入和流出操作。对我而言，它取决于六边形实现的用例以及它使用该端口的原因。 例如我可以想到一个端口“IPersistenceGateway”，它具有读写方法，如“GetUsers”和“SaveUser”。该端口代表所有六边形的持久性抽象;在其他情况下，我可以使用“IReadingPersistenceGateway”和“IWritingPersistenceGateway”，其中上面提到的两个操作被分割为，以便将读/写操作分开“àlaCQRS”。

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

3. 在我上面提到的示例中，端口是“IPersistenceGateway”，可能有一个“MySqlPersisteceGateway”和一个“MongoPersistenceGateway”来管理六边形的截止持久性需求，用于MySql和MongoDb上下文。 / p>

在你的情况下，根据我的理解，我认为JMS适配器可以注入六边形的消息处理程序，因为JMS适配器必须将消息“推送”到六边形而不是相反（xexagon拉动）消息形成适配器）。如果这是正确的，那么（在我看来）没有问题有一个适配器直接引用六边形内的消息处理程序。这一点始终是依赖的方向：总是朝向抽象，从六边形的外部到内部（DIP，依赖性倒置原则）。