目錄
一 軟體架構的4+1模型
二 分層架構風格
三 六邊型架構
四 代碼示例
五 總結
一 軟體架構的4+1模型
先上圖，軟體架構的4+1模型如圖1.1所示：
圖1.1 4+1模型
注：上圖中的元素一詞來源于軟體架構的定義
計算機系統的軟體架構是構建這個系統所需要的一組架構，包括軟體元素、它們之間的關系以及兩者的屬性
-----Bass等著《Documenting Software Architectures:Views and Beyond》
每個視圖的目的如下：
邏輯視圖：以面向物件語言為例，元素包括類和包，它們之間的關系可理解為類和包之間的關系（繼承、關聯和依賴），
實作視圖：構建編譯系統的輸出，該視圖由打包代碼的模塊和組件組成，組件是有一個或多個模塊組成的可執行單元或可部署單元，元素之間的關系為模塊之間的依賴或組合關系，
行程視圖：表示運行時的組件，其中，元素表示一個行程，元素之間的關系為行程間的通信，
部署視圖：表示行程如何映射到機器，其中，元素由機器和行程組成，機器之間的關系為網路，
4 + 1中的1表示場景，場景負責把視圖串聯在一起，每個場景負責描述在一個視圖中的多個架構元素是如何協作來完成一個請求，
二 分層架構風格
分層架構是典型的架構例子，該架構將元素按照“層”的方式組織，每個層有定義明確的職責，同時限制了層與層之間的依賴關系，即：每一層只能依賴于緊鄰的下層或下面的任何層，以常見的三層架構為例（三層架構是應用于邏輯視圖的分層架構），三層架構將應用程式的類組織展示如圖2.1所示：
圖2.1 三層分層架構
在實際開發程序中，三層架構隨著業務的逐漸龐大會出現很明顯的弊端，比如，在表示層中有邏輯層的代碼，導致在實際的三層架構模型中，下層會依賴上層，違背了三層分層機構只能上層依賴下層的原則，導致分層邊界越來越模糊，
三 六邊型架構
為了解決分層架構，隨著業務逐漸判斷導致邊界模糊的問題，六邊形架構應運而生，六邊形架構（也稱為埠-配接器架構）可以看做是分層架構的替代品，如圖3.1所示，
圖3.1 六邊形架構結構圖
六邊形架構風格以業務邏輯為核心的方式組織邏輯視圖，應用具備一個或多個入站配接器，而不是表示層，入站配接器通過呼叫埠來呼叫業務邏輯處理外部的請求，同樣的，應用具備一個或多個出站配接器，而不是資料持久層，出站配接器由業務邏輯中的出站埠呼叫，來呼叫外部系統（mysql，redis，zk等等） ，六邊形架構的一個優點是業務邏輯不依賴于配接器，而是配接器來依賴于業務邏輯，
業務邏輯具有一個或多個埠，在埠中，定義了一組操作，這些操作關于業務如何與外部互動（處理外部請求、呼叫外部系統），以Java開發為例，埠可以理解為Java介面，入站埠是業務邏輯公開的API（如Controller呼叫的業務邏輯介面），供外界呼叫，出站埠是業務邏輯呼叫外部系統的方式，
業務邏輯周圍有配接器，配接器也包括入站配接器和出站配接器，其中，入站配接器通過呼叫入站埠來處理外部的請求，我們常見的入站配接器有Spring MVC的controller，訊息代理客戶端等，特別注意的是，多個入站配接器可以呼叫相同的入站埠，
出站配接器實作出站埠，通過呼叫外部程式/服務/系統的方式來處理業務邏輯的請求，如訪問資料庫，呼叫遠程RPC，發布訂閱時間等等，
六邊形架構的一個重要好處是，它將業務邏輯和配接器的邏輯分離開，和三層分層架構不同的是，業務邏輯不再依賴表示層或資料訪問層，通過這種分離，對業務邏輯進行單獨的測驗變得更容易，六邊形架構更準確地反映了現代應用程式的架構，外部請求通過多個配接器呼叫業務邏輯，業務邏輯也可以呼叫多個出站配接器，每個配接器呼叫不同的外部系統，
四 代碼示例
以Tom Hombergs的代碼為例進行部分說明，代碼地址如下：
https://github.com/thombergs/buckpal，代碼結構如圖4.1所示：
圖4.1 代碼結構
六邊形架構的原則是業務邏輯不能依賴與配接器，而是配接器需要依賴與業務邏輯，以入站配接器為例，SendMoneyController作為一個入站配接器，它需要呼叫入站埠來呼叫業務邏輯實作具體的請求，這里的入站埠為sendMoney(SendMoneyCommand command)方法，如圖4.2所示：
圖4.2 SendMonryCotroller
針對出站配接器，需要采用依賴倒置的原則（高層模塊不應該依賴底層模塊，兩者都應該依賴其抽象；抽象不應該依賴細節，細節應該依賴抽象，一句話總結就是面向介面編程），
在業務邏輯sendMoney方法中，宣告了2個出站埠loadAccountPort和updateAccountStatePort，出站埠LoadAccountPort，UpdateAccountStatePort是兩個介面，由對應的出站配接器去實作，出站埠是定義在業務邏輯中的，根據依賴倒置原則，出站配接器必須依賴于對應的出站配接器，進而依賴于業務邏輯，而不是業務邏輯依賴于出站配接器，實作了LoadAccountPort和UpdateAccountStatePort出站埠的出站配接器如圖4.3所示：
圖4.3 AccountPersistenceAdapter出站配接器
在業務邏輯sendMoney方法中，通過呼叫實作了出站埠的出站配接器的具體方法在完成業務邏輯對外部系統的呼叫，如圖4.4所示
圖4.4 sendMoney業務邏輯
五 總結
以下是個人理解，可能有誤：
在我看來，當一個服務體量不大的時候，三層分層結構和六邊形架構的區別不大，因為在體量不大的情況下，服務的輸入埠和輸出埠較少，可以簡單的將整個服務看做三層分層架構，隨著服務體量的逐漸擴大，六邊形架構的特點會逐漸體現，通過才有依賴倒置，將業務邏輯和輸入、輸出隔離開，這也是六邊形架構以業務為核心的特點，由于這種特性，六邊形架構適用于對業務代碼的測驗，不用依賴于輸入和外部系統，
還是那句話，技術沒有銀彈，選擇什么樣的技術，架構需要從自身的業務考慮，只有適合自己業務的架構，沒有絕對一勞永逸的架構，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/297444.html
標籤：其他
上一篇：VLAN和埠
下一篇：HTTP HTTPS