六邊形之埠和介面卡架構 - cockburn
在90年代中期的某個地方，我開始繪製一個對稱架構，其中資料庫不位於該架構的底部，而是完全在應用程式之外。為了打破過去那種“頂部和底部以及左右兩側”視角看法，我畫了一個六邊形的形狀，並提出了相當愚蠢的名稱：HexagonalArchitecture - 因為我想不出'六邊形'是什麼意思。
六邊形的各個方面代表了應用程式與外部世界的不同對話。以下是我的一位朋友正在建造的系統中的一個例子，該系統接受了氣象局關於龍捲風和山洪的通知，並且會給人們打電話並在他們的應答機上留下關於疏散程式的資訊。在通用實現中，實際上是他正在使用的是，將有技術驅動的介面，一個用於http協議，一個用於應答機器，一個用於人，一個用於資料庫。我的朋友在進展過程中遇到了維護和擴充套件系統的麻煩。我們一起確定了以下不同型別的對話：
- 關於天氣事件的通知
- 資料庫的資料，比如誰訂閱以及他們想要傳送通知的地方
- 疏散程式的資料，無論是發給人還是錄音裝置
- 管理控制，例如設定通知事件，計費，更新使用者群，應用程式引數等
我們看到有四個根本不同的對話，並且說應用程式應該為每個對話都有一個API，並通過這四個埠與位於埠另一側的任何埠進行通訊。他會為每個的不同技術建立一個介面卡 。
為了證明埠的這種想法，我們想測試每個埠的另一端確實存在多種外部技術，因此值得使用介面卡來調整外部技術到API。
這是我遇到的“埠”概念的最明確的用法 - 通常只有2個：使用者和資料庫。
六邊形（埠）的每個面都代表了應用程式試圖與外界交談的一些“原因”。活動從外部世界到達埠。介面卡將其轉換為可用的過程呼叫或訊息，並將其傳遞給應用程式。該應用程式對輸入裝置的性質一無所知（另請參閱Ward的CHECKS模式語言，http： //c2.com/ppr/checks.html）。當應用程式傳送內容時，它會將埠傳送到介面卡，從而建立接收技術（人工或自動）所需的適當訊號。該應用程式在其所有側面與介面卡進行語義上的聲音互動，而實際上並不知道介面卡另一側的物體的性質。