六边形之端口和适配器架构 - cockburn

在90年代中期的某个地方，我开始绘制一个对称架构，其中数据库不位于该架构的底部，而是完全在应用程序之外。为了打破过去那种“顶部和底部以及左右两侧”视角看法，我画了一个六边形的形状，并提出了相当愚蠢的名称：HexagonalArchitecture - 因为我想不出'六边形'是什么意思。

六边形的各个方面代表了应用程序与外部世界的不同对话。以下是我的一位朋友正在建造的系统中的一个例子，该系统接受了气象局关于龙卷风和山洪的通知，并且会给人们打电话并在他们的应答机上留下关于疏散程序的信息。在通用实现中，实际上是他正在使用的是，将有技术驱动的接口，一个用于http协议，一个用于应答机器，一个用于人，一个用于数据库。我的朋友在进展过程中遇到了维护和扩展系统的麻烦。我们一起确定了以下不同类型的对话：

• 关于天气事件的通知
• 数据库的数据，比如谁订阅以及他们想要发送通知的地方
• 疏散程序的数据，无论是发给人还是录音设备
• 管理控制，例如设置通知事件，计费，更新用户群，应用程序参数等

这是我遇到的“端口”概念的最明确的用法 - 通常只有2个：用户和数据库。
六边形（端口）的每个面都代表了应用程序试图与外界交谈的一些“原因”。活动从外部世界到达端口。适配器将其转换为可用的过程调用或消息，并将其传递给应用程序。该应用程序对输入设备的性质一无所知（另请参阅Ward的CHECKS模式语言，http：//c2.com/ppr/checks.html）。当应用程序发送内容时，它会将端口发送到适配器，从而创建接收技术（人工或自动）所需的适当信号。该应用程序在其所有侧面与适配器进行语义上的声音交互，而实际上并不知道适配器另一侧的物体的性质。

banq注：MVC模式其实应该是MVA模式，控制器准确按照六边形架构是适配器。MVA模式见这里