六角形建築原義 - AlistairCockburn
我在 http://alistair.cockburn.us/index.php/Hexagonal_architecture 上發了一篇完整的文章。
最後，經過多年，我更好地理解了這個架構的含義，並轉而稱之為 PortsAndAdaptersArchitecture ，因為六邊形的每個方面代表一個埠（一個獨立於技術的協議，捕獲討論的理由），以及外層是GoF風格的介面卡，將該協議對映到不同的外部技術。我想下一步是更好地定義什麼構成'埠'。- AlistairCockburn
這是我對分層架構的標準討論的迴應。正是 FourLayerArchitecture 中的一行引發了這一寫作，即“基礎設施層。這是表示與應用程式外部實體（特別是物件世界之外的實體）的連線的物件所在的位置。”
我將標準分層模型視為更通用且更適用的模型的特例。通過“標準分層模型”我的意思是：UI - >應用程式 - >領域 - >網路和資料庫。
對我來說，網路和資料庫與坐在螢幕上工作的人相比沒有什麼不同。
事實上，我故意希望沒有什麼區別。我特別希望用一個裝滿測試用例的平面檔案替換坐在螢幕上的人，用一個EDI連結到另一家公司的計算機，開發人員在表單視窗列印文件，其中帶有到另一個本地程式的熱連結。此外，我希望用本地的固定指令碼或演示資料庫替換網路和資料庫，使用GUI和開發人員通過特定的連結即時傳送資料。
我內心是對稱主義者。我希望在某個時刻一切都是對稱的，並從那裡解決差異。所以我建立了一個分層模型的對稱版本，其中UI不是在前面，而DB是在後面（這不是對稱，這是線形流），兩者都應該在外面。現在分層架構看起來像這樣：
> OUTSIDE < - > transformer < - >（application < - > domain）
我把它畫成同心六邊形。我把這個人放在左上方，網路/ DB放在右上方，一個印表機外面有一個印表機，一個衛星，以及我能想到的任何其他東西。外六角形內部是較小的六邊形。兩者之間是變壓器層中的變壓器物件。內部六邊形內部是應用程式物件和域物件，有些人喜歡分層，有些人喜歡不分層。
應用程式的工作方式如下：事件來自外部世界。transformer變換器將其轉換為可用的過程呼叫或訊息，並將其傳遞給應用程式。該應用程式對輸入裝置的性質一無所知（另請參閱Ward的CHECKS模式語言， http： //c2.com/ppr/checks.html）。這樣做，最終可以獲得應用程式的迴歸測試。在“後端”（六邊形沒有後端），網路層實際上是另一個轉換為特定輸出形式的變換器transformer層，即您正在使用的特定網路和資料庫。當應用程式有東西向坐在螢幕上的人報告時，它會向變換器傳遞一個語義上有意義的訊息，變換器將其轉換為合適的輸出形式。該應用程式與變換器在其各個方面進行語義上的聲音互動，而實際上並不知道Actor角色的本質。
六邊形的每個面都代表了應用程式試圖與外界交談的一些“原因”。這就是為什麼它是同心六邊形而不是同心圓。在我繪製它時，左上角的輸入控制元件，右側的儲存和輔助輸入。在一些更詳細的架構正式演繹中，我可能稱之為埠。
我經常需要使用固定的資料片段開始新的一天，而不是指向實時資料庫的連結。在基本的電子設計中，他們將其稱為“ LoopBack ”（我錯誤地將其稱為 ShuntPattern 很長一段時間） - 從外部埠進入內部埠的一根導線，因此機器與自身對話而不是另一端機器。這種分流將整個通訊系統放在開發人員的桌面上，他可以在那裡處理它。
重點是，有東西進入並且有東西出來了，我們經常需要將不同的技術插入到內部和外部。如果我可以將資料庫輸出重定向到我自己坐在螢幕上並輸入我自己的資料，如果我可以將自己的答案放入檔案中並且該檔案對應用程式起到快速打字員的作用，那麼在開發時我會是一個更快樂的露營者，測試和部署。
你們中的一些人也可能認為這是 UserInterfaceOutside 模式的擴充套件，這一原則最初出現在我的PLOP論文“軟體架構中的優先順序”（PLOP2書）和後來的CACM論文“社會問題和軟體架構”中。- AlistairCockburn
(banq注：六邊形架構核心是對稱，同心圓，萬眾向心，UI介面和Oracle資料庫都屬於同心圓外邊，不是圓心，業務邏輯才是圓心，可以更換不同的UI和不同資料庫進行測試，目前Spring Boot的REST屬於UI的介面卡，也是與外部整合的介面卡；JDBC是與具體資料庫的介面卡，訊息系統也是一種介面卡)