端口和适配器/六角形体系结构-术语和实现的说明 [英] Ports and adapters / hexagonal architecture - clarification of terms and implementation

问题描述

在阅读有关Ports&适配器架构，包括Alistair Cockburn的原始文章 >我仍然不确定术语端口"和适配器"的确切含义，尤其是在将这些概念映射到实现工件时.

多个来源(例如这篇文章 )表示此架构模式中的 ports 是位于外部的工件，其次是中间层的 adapters ，它们在 ports 之间转换以及位于核心位置的 application .

但是，在Cockburn的原始文章中，端口出现在 adapter 层的外部和内部，具体取决于通信方向:

• 入站通信:"事件从外部世界到达端口时，特定于技术的适配器将其转换为可用的过程调用或消息，并将其传递给应用程序."
• 出站通信:"当应用程序有待发送的东西时，它通过端口将其发送到适配器，适配器会创建接收技术(人为或自动化)所需的适当信号. "

实际上，对于我来说，所有外部"方法和内部和外部"方法都没有道理-我会把 ports 视为始终放置在应用程序旁边的构件，而与方向无关沟通.同时，这也与 port 和 adapter 隐喻一致:拥有一个带有串行端口的设备，要连接另一个没有串行端口的设备，我需要一个适配器，该适配器可以从我的设备角度适应入站和出站通信.

在实现此体系结构时，我会看到 ports 的定义，而不是作为我的应用程序的一部分，在那里我会看到不同的 adapters 我的应用程序的外部".例如单个 port 的实现可以由facade(由适配器进行入站通信调用)和interface(由适配器进行出站通信实现)组成.

端口 和适配器的正确含义是什么?这些概念如何映射到实现工件上?

更新:

找到与我的理解类似的这篇文章.问题是否存在某种共同的共识.

解决方案

inf3rno给出了一个很好的答案，阐明了原始问题，但是突出显示端口和适配器的其他用途可能很有用.

据我了解，端口是您界面的一种表达方式.

端口:

• 定义内核功能的公开性(用于传入"端口)
• 定义核心对外部世界的看法(对于出站"端口)

适配器:

• 位于组件(六边形)之外
• 用于确保端口与目标之间的传输以与端口接口满足合同的方式发生
• 是您要替换的对象(使用依赖项注入)来测试六边形

端口应接受适配器并确保适配器实现了接口.然后，它只应在适配器上调用适当的方法/功能.

该端口应包括在通信测试中.在这种情况下，模拟"的是两个相邻六边形(或一个六边形和一个服务)的核心，并测试端口/适配器/适配器/端口组件.

有关更多信息，您可以查看我和James Gardner在伦敦的Skillsmatter Microservices上发表的关于六角微服务的演讲 2014年7月聚会.

After reading different sources about the Ports & Adapters architecture including Alistair Cockburn's original article I am still not sure about the definite meaning of the terms "port" and "adapter" - especially when it comes to mapping these concepts to implementation artifacts.

Several sources (e. g. this post) imply that the ports in this architecture pattern are artifacts at the very outside, followed by the adapters in the intermediate layer that translate between the ports and the application that is at the heart.

However, in Cockburn's original article the ports appear at the outside as well as on the inside of the adapter layer dependent on the direction of communication:

• Inbound communication: "As events arrive from the outside world at a port, a technology-specific adapter converts it into a usable procedure call or message and passes it to the application."
• Outbound communication: "When the application has something to send out, it sends it out through a port to an adapter, which creates the appropriate signals needed by the receiving technology (human or automated)."

Actually for me neither the "all outside" approach nor the "inside and outside" approach make sense - I would see the ports as artifacts that are always placed next to the application regardless of the direction of communication. Imo this would also be consistent with the port and adapter metaphors: E. g. having a device with a serial port, to connect another device without a serial port to this I'd need an adapter that adapts inbound and outbound communication from the viewpoint of my device.

Coming to the implementation of this architecture I'd see the definition of the ports rather as a part of my application where I'd see the different adapters as being "outside" of my application. E. g. an implementation of a single port could consist of a facade (to be called by adapters for inbound communication) and an interface (to be implemented by adapters for outbound communication).

What is the correct meaning of the terms port and adapter and how can these concepts be mapped to implementation artifacts?

UPDATE:

Found this article which resembles my understanding. The question remains if there is some kind of common agreement.

解决方案

inf3rno gave a good answer which clarifies the original question, but it may be useful to highlight some other uses for ports and adapters.

According to my understanding the port is an expression of your interface.

The port:

• Defines the exposure of the core's functionality (for 'incoming' ports)
• Defines the core's view of the outside world (for 'outgoing' ports)

The adapter:

• Is located outside the component (hexagon)
• Is used to ensure that the transport between port and the target happens in a way that satisfies the contract with the port's interface
• Is what you replace (using dependency injection) to test the hexagon

The port should accept the adapter and make sure that the adapter implements the interface. Then it should merely call the appropriate methods/functions on the adapter.

The port should be included in communication testing. In that case, what is 'mocked out' is the cores of two neighbouring hexagons (or a hexagon and a service) and test the port/adapter/adapter/port assembly.

For more information you can view the talk about Hexagonal Microservices that James Gardner and I gave at London's Skillsmatter Microservices meetup in July 2014.

这篇关于端口和适配器/六角形体系结构-术语和实现的说明的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！