為什麼需要六邊形架構？- silkandspinach
傳統應用程式架構的標準三層或四層模型似乎決定了系統中各種物件之間的依賴關係的方向：UI依賴於應用程式層，因為UI“驅動”後面發生的事情；應用程式層依賴於業務物件，業務物件執行所有特定於領域的事務，業務物件使用（因此依賴於）持久層和通訊層，這兩個層又使用並依賴於外部API。以這種方式實現分層模型好像很自然。
ui ---> application ---> domain --->（persistence，comms）
正是這種分層模型使許多應用程式難以或無法測試。這些感知的依賴關係中的每一層最終都體現在程式碼結構中，並且通過隱身設計已經具體化變成分層模型。在這一點上，像我一樣的人會叮囑開發人員提高他們的測試覆蓋率，但是我會被告知：“我們嘗試過，但管理和準備需要測試GUI的Oracle測試資料需要很長時間”。或者當業務決定切換到新的資料庫或企業通訊架構，需要重新設計大量的業務邏輯。
Alistair Cockburn的六邊形建築 模型引入了一個對稱軸，可以幫助我們瞭解如何解決這些問題：
我們應該使用內部 - 外部模型來檢視一個應用程式架構，而不是使用分層模型的上下視角。領域物件位於中間，並通過我稱之為介面卡： 比如一個 GUI，CGI指令碼，命令列，硬體控制器，列印後臺處理程式等連線到現實世界。每個介面卡將領域物件連線到不同的“真實”世界的一部分。
因此，讓我們從“六角形”的角度來看待我們的不可測試或不可移植的應用程式。（請記住，我們在這裡仍然在討論相同的程式碼庫：只是我們的話語模型已經發生了變化。）使測試變得如此困難的依賴性，以及對分層模型的天真解釋而存在的依賴性，顯然違背了六角形模型的對稱性。
ui --->（app，domain）--->service
如果我們希望能夠輕鬆移植應用程式以使用不同的服務，我們需要能夠輕鬆地替換掉將我們連線到這些服務的介面卡。
ui --->（app，domain）--->new service
如果我們希望獨立於硬體測試領域物件，我們需要能夠用stubs存根，分流器或模擬Mock 物件替換各種介面卡。
fit ---> (app, domain) ---> mock services
我們目前無法做到這一點，因為該設計違反了Bertrand Meyer的開放式原則（“ 系統應該向擴充套件開放，但不能修改 ”）。為了解決這個問題，我們需要使用Uncle Bob的依賴倒置原則 ：我們在中間的六邊形中引入抽象，以便目前的介面卡實現這些抽象。
ui --->（app，domain ---> abstraction）<--- service
現在恢復了對稱性：每個介面卡都依賴於中間六邊形，而中間六邊形（我們的域物件）獨立於使用它的物理上下文。
介面卡--->中間<---介面卡
現在我們可以更容易地看到如何剝離我們希望的任何介面卡，並用模擬物件或不同的服務替換它們。介面卡/中間對稱軸是提高企業應用程式的可測試性和可移植性的關鍵因素。