我阅读了有关 Alistair Cockburn 提出的端口和适配器架构的不同来源，发现它适合我开发网关服务应用程序的场景，该应用程序从多个源接收消息并处理消息并将消息发送到多个目的地。这是我的详细实现。
- 目前消息源是单一的(JMS Queue)
- JMS 端口订阅 JMS 消息队列并将其传递给 JMS 适配器，后者又调用相应的消息处理程序。
- 消息处理程序依次调用业务域层，该层独立于消息的源或目标，如 cockburn 所建议的那样。
- 具有依赖注入(inject)容器注入(inject)的 JMS 端口、WCF 端口、DB 端口、TCP 端口的消息处理程序依次调用 JMS 端口、TCP 端口和 WCF 端口来发布/发送域处理的消息。
如果我是否偏离了 Cockburn 提出的架构，我有几个关键问题/疑虑。
- 单个端口能否处理消息的流入/流出(在本例中为 JMS 端口)。还是为消息的流入和流出设置单独的端口是一个好习惯。
2.根据cockburn的文章说
入站通信:“当事件从外部世界到达端口时，特定技术的适配器将其转换为可用的过程调用或消息，并将其传递给应用程序。”
出站通信:“当应用程序有东西要发送时，它会通过端口将其发送到适配器，适配器会创建接收技术(人工或自动)所需的适当信号。”
所以我将处理后的消息直接传递到端口，该端口又调用适配器根据目标要求转换消息。
Message Handlers(Application Layer)能否依赖注入(inject)的Ports？
根据 Cockburn 的文章，它说
通常会有多个适配器用于任何一个端口，用于可能插入该端口的各种技术。
我想不出单个端口需要多个适配器的场景。您能否给我一个场景，以便我可以充分利用该架构。
最佳答案
这是我的观点:
是的，一个端口可以同时进行流入和流出操作。对我来说，这取决于六边形实现的用例以及它使用该端口的原因。 例如我可以想到一个端口“IPersistenceGateway”，它具有像“GetUsers”和“SaveUser”这样的读写方法。该端口代表所有六边形的持久化抽象；在其他情况下，我可以有“IReadingPersistenceGateway”和“IWritingPersistenceGateway”，其中上面提到的两个操作被拆分到，以便将读/写操作“à la CQRS”分开。
我认为您的“应用程序层”应该被视为“六边形内部”:所以是的，消息处理程序可以注入(inject)端口依赖项。我认为消息处理程序应该是唯一从六边形外部可见的对象，因此是第一个获得端口的对象，由外部注入(inject)。
在我上面提到的示例中，端口是“IPersistenceGateway”，对于 MySql 和 MongoDb 上下文，可能有一个“MySqlPersisteceGateway”和一个“MongoPersistenceGateway”来管理六边形的抽象持久性需求。
在你的情况下，据我所知，我认为 JMS 适配器可能已经注入(inject)了六边形的消息处理程序，因为 JMS 适配器必须将消息“推送”到六边形而不是反之(拉动的 xexagon消息形成一个适配器)。如果这是正确的，那么(在我看来)拥有一个直接引用六边形内的消息处理程序的适配器就没有问题。重点始终是依赖的方向:始终朝向抽象，从六边形的外部到内部(DIP，依赖倒置原则)。
关于design-patterns - Windows 服务的六边形架构/端口和适配器架构。正确的路？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29489315/