六邊形之埠和介面卡架構 - cockburn

banq發表於2019-02-04
架構
在90年代中期的某個地方，我開始繪製一個對稱架構，其中資料庫不位於該架構的底部，而是完全在應用程式之外。為了打破過去那種“頂部和底部以及左右兩側”視角看法，我畫了一個六邊形的形狀，並提出了相當愚蠢的名稱：HexagonalArchitecture - 因為我想不出'六邊形'是什麼意思。

六邊形的各個方面代表了應用程式與外部世界的不同對話。以下是我的一位朋友正在建造的系統中的一個例子，該系統接受了氣象局關於龍捲風和山洪的通知，並且會給人們打電話並在他們的應答機上留下關於疏散程式的資訊。在通用實現中，實際上是他正在使用的是，將有技術驅動的介面，一個用於http協議，一個用於應答機器，一個用於人，一個用於資料庫。我的朋友在進展過程中遇到了維護和擴充套件系統的麻煩。我們一起確定了以下不同型別的對話：
  • 關於天氣事件的通知
  • 資料庫的資料，比如誰訂閱以及他們想要傳送通知的地方
  • 疏散程式的資料，無論是發給人還是錄音裝置
  • 管理控制，例如設定通知事件，計費，更新使用者群，應用程式引數等

我們看到有四個根本不同的對話，並且說應用程式應該為每個對話都有一個API，並透過這四個埠與位於埠另一側的任何埠進行通訊。他會為每個的不同技術建立一個介面卡。
為了證明埠的這種想法，我們想測試每個埠的另一端確實存在多種外部技術，因此值得使用介面卡來調整外部技術到API。

這是我遇到的“埠”概念的最明確的用法 - 通常只有2個：使用者和資料庫。
六邊形（埠）的每個面都代表了應用程式試圖與外界交談的一些“原因”。活動從外部世界到達埠。介面卡將其轉換為可用的過程呼叫或訊息，並將其傳遞給應用程式。該應用程式對輸入裝置的性質一無所知（另請參閱Ward的CHECKS模式語言，http：//c2.com/ppr/checks.html）。當應用程式傳送內容時，它會將埠傳送到介面卡，從而建立接收技術（人工或自動）所需的適當訊號。該應用程式在其所有側面與介面卡進行語義上的聲音互動，而實際上並不知道介面卡另一側的物體的性質。

banq注：MVC模式其實應該是MVA模式，控制器準確按照六邊形架構是介面卡。MVA模式見這裡
 

相關文章