六邊形架構

前言

注: 當我在學習DDD時，看到其中的六邊架構，在初步瞭解其架構思想以後，就深深地被吸引了，由於它能夠解決諸多我在項目中遇到的問題。

這裏將着重介紹六邊形架構的思想，以及其解決的問題，並不與其它架構作深刻的對比。

六邊形架構 又被稱之爲ports&adpers(我認爲這個名稱更合適)，是 Cockburn在2005年提出的，目的是爲了解決業務邏輯與輸入輸出的解耦。

架構思想

想像一下電腦如何與周邊設備如何交互的：

周邊設備有耳機、鍵盤、外接顯示器、耳機等，它們經過電腦的USB、HDMI等端口進行鏈接；但有時剛買來一個新的設備(好比打印機)，想經過USB與電腦鏈接，但你插上時，電腦卻提示你沒法識別，須要安裝驅動，你按照說明，安裝好驅動就可使用了。並且比較神奇的是，我有兩個鼠標，一個是ps/2接口，一個是USB接口，但插上去均可以用， 這是由於系統中安裝了兩種接口類型的驅動（適配器)。

經過上面的描述，咱們知道，電腦與周邊設備是經過端口與驅動（適配器）交互的，且只須要有相應的驅動，端口能夠和不一樣的設備進行交互。

咱們在設計架構和編碼過程當中常常犯一個錯誤，將業務邏輯與外部實體間的交互糾纏在一塊兒。好比，在分層架構中，對數據庫的訪問和外部接口的訪問一般放在gateway中，而因爲分層構架，只作了業務的職現劃分，並未作層次的解耦，形成對於外部的訪問成了業務邏輯的內核；一樣，對於對外提供的接口，封裝在controller中，也是一樣的道理。（固然，這裏並非說分層架構很差，只是處理問題的角度不一樣）。

六邊形架構關注的是「外部」和「內部」的差異，內部業務邏輯（Application)與外設（APP,WEB，數據庫等）徹底隔離，僅經過Adapter 進行交互。

那Adapter起什麼做用呢？它負責將與外設交互的數據（包括命令、query）轉化爲Application能夠理解的信息（業務module）,並經過內部系統提供的接口進行業務邏輯的處理。

說了那麼多adpter,那port該如何界定其職責呢？ 咱們知道，電腦上端口定義了設備的通訊協議，只要是相同的端口，不管是什麼設備必須遵循這個協議，只是其通訊的內容可能有所不一樣。對於軟件系統來說，port上端口協議的體現就是api,即業務系統對外暴露的接口，一個端口能夠有多個適配器。好比一個系統提供產口的信息的展現，這時候該信息可能須要在app,web或者做爲遠程服務對外提供產品信息，這時候由Application是提供一個query 接口，並返回一個Product對象，至於要將其轉換成app,web或者遠程服務json格式，則由adapter來完成。

爲何它叫六邊形架構呢？六邊形的一個邊就表明一個端口，但並不表明一個六邊型架構就必須有6個端口，其實這和六個邊沒有任何關係，做者只是爲了方便表達本身的思想，將架構畫成了六邊形，也方便使用者可以在業務架構時，更方便的設計。

這裏仍是提醒一下，雖然六邊形強調內部和外部的區別，但並不表明咱們不關注外部接口的主被動（對外提供服務，仍是調用外部服務），但咱們能夠在實現端口和adapters 時，經過技術來屏蔽這種差別，但卻不適合，也不必使用一個徹底相同的端口來屏蔽這種差別。因此通常的六邊形架構架構會在左右兩端各有端口，左邊表明對外提供服務，右邊表明調用外部服務。

經過上面的介紹，相信你已經瞭解了六邊形的設計思想。那它這種業務邏輯和外部系統的分離，還給咱們帶來什麼好處呢？

如上圖所示，應用外對提供了兩個端口，用戶側API和數據側API。用戶側API，經過四個適配器爲app,http,GUI,ie提供服務；數據側經過兩個適配器（DB和mock）爲應用提供適配服務。你們看到這裏，可能會有些吃驚，怎麼還有mock?

是的，只須要實現data-side端口的的服務均可覺得Application提供數據，對系統來講並不會感知到服務的差別，也就是說mock和db 能夠提供無差別的服務。說到這裏你就明白了，不再用將測試用例嵌入到業務邏輯中了，只要實現相應的adapter就能夠了，不再用由於業務代碼的變更而更改測試用例。爲集成化測試提供了很大的方便。

稍後我會補充一個項目案例！！！！

http://alistair.cockburn.us/Hexagonal+architecture