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

19-02-04 banq
                   

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

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

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

我们看到有四个根本不同的对话,并且说应用程序应该为每个对话都有一个API,并通过这四个端口与位于端口另一侧的任何端口进行通信。他会为每个的不同技术创建一个适配器

为了证明端口的这种想法,我们想测试每个端口的另一端确实存在多种外部技术,因此值得使用适配器来调整外部技术到API。

这是我遇到的“端口”概念的最明确的用法 - 通常只有2个:用户和数据库。

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

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