六邊形架構或六角架構是Alistair Cockburn在2005年提出，解決了傳統的分層架構所帶來的問題，實際上它也是一種分層架構，只不過不是上下或左右，而是變成了內部和外部。在領域驅動設計(DDD)和微服務架構中都出現了六邊形架構的身影，在《實現領域驅動設計》一書中，作者將六邊形架構應用到領域驅動設計的實現，六邊形的內部代表了application和domain層，而在Chris Richardson對微服務架構模式的定義中，每個微服務使用六邊形架構設計，足見六邊形架構的重要性。那么讓我們一探究竟，它為何如此受青睞。

問題

傳統的分層架構具有廣泛的應用，例如經典的三層架構，把系統分為表示層、業務邏輯層、數據訪問層。在Martin Fowler的《企業應用架構模式》一書中做過深入闡述，本書04年出版，時至今日分層架構仍然是常用的設計方法，分層架構可以降低耦合、提高復用、分而治之，但同時也還是存在一些問題：

應用邏輯在不同層泄露，導致替換某一層變得困難、難以對核心邏輯完整測試：你是否有過困惑，代碼到底應該放在哪個層，雖然定義了各層的職責，但是總有人不嚴格遵循層次的分界，對于三層架構，常常會出現業務邏輯寫在了表示層，或者業務邏輯直接和數據訪問綁定。

傳統的分層架構是一維的結構，有時應用不光是上下的依賴，可能是多維的依賴，這時一維的結構就無法適應了。

六邊形架構又稱為端口-適配器，這個名字更容器理解。六邊形架構將系統分為內部(內部六邊形)和外部，內部代表了應用的業務邏輯，外部代表應用的驅動邏輯、基礎設施或其他應用。內部通過端口和外部系統通信，端口代表了一定協議，以API呈現。一個端口可能對應多個外部系統，不同的外部系統需要使用不同的適配器，適配器負責對協議進行轉換。這樣就使得應用程序能夠以一致的方式被用戶、程序、自動化測試、批處理腳本所驅動，并且，可以在與實際運行的設備和數據庫相隔離的情況下開發和測試。

內涵

六邊形架構的重點體現在以下幾個方面：

關注點

對于分層架構中層次的界定，Martin Fowler給出了一個判定的方法，就是如果把表示層換成其他實現，如果和原來的表示層有重復實現的內容，那么這部分內容就應該放到業務邏輯層。那么如何讓開發人員在系統設計過程中始終保持這種視角，傳統的分層架構是難以做到的。六邊形架構有一個明確的關注點，從一開始就強調把重心放在業務邏輯上，外部的驅動邏輯或被驅動邏輯存在可變性、可替換性，依賴具體技術細節。而業務邏輯相對更加穩定，體現應用的核心價值，需要被詳盡的測試。

外部可替換

一個端口對應多個適配器，是對一類外部系統的歸納，它體現了對外部的抽象。應用通過端口為外界提供服務，這些端口需要被良好的設計和測試。內部不關心外部如何使用端口，從一開始就要假定外部使用者是可替換的。六邊形的六并沒有實質意義，只是為了留足夠的空間放置端口和適配器，一般端口數不會超過4個。適配器可以分為2類，“主”、“從”適配器，也可稱為“驅動者”和“被驅動者”。

自動測試

在六邊形架構中，自動化測試和用戶具有同等的地位，在實現用戶界面的同時就需要考慮自動化測試。它們對應相同的端口。六邊形架構不僅讓自動化測試這件事情成為設計第一要素，同時自動化測試也保證應用邏輯不會泄露到用戶界面，在技術上保證了層次的分界。

依賴倒置

六邊形架構必須遵循如下規則：內部相關的代碼不能泄露到外部。所謂的泄露是指不能出現內部依賴外部的情況，只能外部依賴內部，這樣才能保證外部是可以替換的。對于驅動者適配器，就是外部依賴內部的。但是對于被驅動者適配器，實際是內部依賴外部，這時需要使用依賴倒置，由驅動者適配器將被驅動者適配器注入到應用內部，這時端口的定義在應用內部，但是實現是由適配器實現。

總結

以上是生活随笔為你收集整理的android 六边形简书,深入理解六边形架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。