Hexagonal Architecture于2005年由Alistair Cockburn撰寫，是一個具有許多優(yōu)勢的軟件架構(gòu)，自2015年以來又重新引起了人們的興趣。

六角架構(gòu)的初衷是：

允許應(yīng)用程序同樣由用戶，程序，自動化測試或批處理腳本驅(qū)動，并與最終的運(yùn)行時設(shè)備和數(shù)據(jù)庫隔離開發(fā)和測試。

為了探索通過自動化測試引導(dǎo)應(yīng)用程序的好處，或者從數(shù)據(jù)庫中單獨開發(fā)和測試，我們建議您閱讀我們最近發(fā)布的測試金字塔上的這一系列博客文章：實踐中的測試金字塔。

承諾非常有吸引力，它還有另一個有益效果：它允許隔離應(yīng)用程序的核心業(yè)務(wù)，并自動測試其行為，而不依賴于其他任何事情。這可能是該架構(gòu)引起域驅(qū)動設(shè)計（DDD）從業(yè)者關(guān)注的原因。但要小心，DDD和六邊形結(jié)構(gòu)是兩個相當(dāng)不同的概念，它們可以相互加強(qiáng)，但不一定一起使用。但這是另一個時間的主題！

最后，這種架構(gòu)設(shè)置起來并不復(fù)雜。它基于一些簡單的規(guī)則和原則。讓我們探索這些原則，看看它們在實踐中的含義。

• 六角架構(gòu)原理
• 細(xì)節(jié)：內(nèi)部和外部的代碼如何組織？
• 細(xì)節(jié)：運(yùn)行時
• 細(xì)節(jié)：右側(cè)的依賴性反轉(zhuǎn)
• 細(xì)節(jié)：為什么左邊有借口？
• 六角形結(jié)構(gòu)測試
• 更進(jìn)一步
• 參考

六角架構(gòu)學(xué)原理

六邊形體系結(jié)構(gòu)基于三個原則和技術(shù)：

• 明確區(qū)分應(yīng)用程序，域和基礎(chǔ)結(jié)構(gòu)
• 依賴關(guān)系從應(yīng)用程序和基礎(chǔ)結(jié)構(gòu)到域
• 我們使用端口和適配器隔離邊界

詞匯說明：在本文的其余部分中，將使用“應(yīng)用程序”，“域”和“基礎(chǔ)結(jié)構(gòu)”等字樣。這些詞不是來自原始文章，而是來自領(lǐng)域驅(qū)動設(shè)計從業(yè)者頻繁使用六邊形體系結(jié)構(gòu)。作為參考，原始文章的文字在下面的部分中說明。

原則：單獨的應(yīng)用程序，域和基礎(chǔ)結(jié)構(gòu)

第一個原則是明確地將代碼分成三個大的形式化區(qū)域。

左側(cè)，應(yīng)用程序端

這是用戶或外部程序與應(yīng)用程序交互的一面。它包含允許這些交互的代碼。通常，您的用戶界面代碼，API的HTTP路由，以及使用您的應(yīng)用程序的程序的JSON序列化都在這里。

這是我們找到驅(qū)動領(lǐng)域的演員的一面。

注意：Alistair Cockburn談?wù)搼?yīng)用程序方面的左側(cè)或用戶側(cè)。

領(lǐng)域，在中心

這是我們想要從左側(cè)和右側(cè)隔離的部分。它包含所有關(guān)注和實現(xiàn)業(yè)務(wù)邏輯的代碼。業(yè)務(wù)詞匯和純粹的業(yè)務(wù)邏輯，與解決您的應(yīng)用程序的具體問題，使其豐富和具體的所有內(nèi)容相關(guān)聯(lián)，處于中心位置。理想情況下，不知道如何編碼的領(lǐng)域?qū)＜铱梢蚤喿x本部分中的一段代碼并指出您的不一致（真實的故事，這些都可能發(fā)生在您身上！）。

注意：Alistair Cockburn談?wù)撚虻闹行幕驑I(yè)務(wù)邏輯。

右側(cè)，基礎(chǔ)設(shè)施方面

在這里，我們可以找到您的應(yīng)用程序需要什么，它驅(qū)動的工作。它包含必要的基礎(chǔ)結(jié)構(gòu)詳細(xì)信息，例如與數(shù)據(jù)庫交互的代碼，調(diào)用文件系統(tǒng)或處理對您所依賴的其他應(yīng)用程序的HTTP調(diào)用的代碼。

這是我們找到由領(lǐng)域管理的演員的一面。

注意：Alistair Cockburn談?wù)摶A(chǔ)設(shè)施方面的右側(cè)或服務(wù)器端。

以下原則將允許在應(yīng)用程序，域和基礎(chǔ)結(jié)構(gòu)之間實現(xiàn)這種邏輯分離。

為什么這很重要？

這種分離的第一個重要特征是它將問題分開。在任何時候，您都可以選擇專注于單個邏輯，幾乎獨立于其他兩個邏輯：應(yīng)用程序邏輯，業(yè)務(wù)邏輯或基礎(chǔ)架構(gòu)邏輯。它們在不混合的情況下更容易理解，并且每個邏輯的約束對其他邏輯的影響較小。

另一個特點是我們將業(yè)務(wù)邏輯放在代碼的最前端。它可以在目錄或模塊中隔離，以使其對所有開發(fā)人員都明確。它可以在不承擔(dān)程序其余部分的認(rèn)知負(fù)荷的情況下進(jìn)行定義，改進(jìn)和測試。這很重要，因為最終，開發(fā)人員對生產(chǎn)中的業(yè)務(wù)有了解。

最后，在自動化測試方面（我們將在下面看到），我們將以合理的努力成功進(jìn)行測試：

1. 整個域單獨，
2. 在Infrastructure端獨立地集成Application和Domain
3. 在應(yīng)用程序端獨立地集成域和基礎(chǔ)架構(gòu)

插圖：應(yīng)用程序的一個小例子

為了更具體地說明這些原則，我們將使用Alistair期間在“Hexagon”事件中使用的小例子，該事件由Thomas Pierrain（@tpierrain）和Alistair Cockburn（@TotherAlistair）于2017年提出。注意：您可以在文章末尾找到視頻和事件代碼。

這個小應(yīng)用程序的目的是提供一個命令行程序，將詩歌寫入控制臺的標(biāo)準(zhǔn)輸出。

此應(yīng)用程序的預(yù)期輸出示例：

$ ./printPoem
Here is some poem:
I want to sleep
Swat the files
Softly, please.
-- Masaoka Shiki (1867 - 1902)
Type enter to exit...

為了正確地說明三個區(qū)域（應(yīng)用程序，域，基礎(chǔ)設(shè)施），此應(yīng)用程序?qū)⒃谕獠肯到y(tǒng)中搜索詩歌：文件。我們還可以將此應(yīng)用程序連接到數(shù)據(jù)庫，原則是相同的。

在這種情況下，我們?nèi)绾螒?yīng)用這第一個原則，即分成三個區(qū)域？如何在左側(cè)（什么驅(qū)動它），在中心（核心業(yè)務(wù)）和右側(cè)（什么是驅(qū)動）分發(fā)？

應(yīng)用方面

從用戶的角度來看，程序是作為控制臺應(yīng)用程序呈現(xiàn)的。因此，控制臺的概念將位于應(yīng)用程序端的左側(cè)。通過控制臺，用戶將驅(qū)動領(lǐng)域。

基礎(chǔ)設(shè)施方面

從技術(shù)上講，在我們的例子中，詩歌存儲在一個文件中。這個文件的概念將在基礎(chǔ)設(shè)施方面的右側(cè)找到。該企業(yè)將通過試用這一右側(cè)來提出其詩歌的要求，具體由PoetryLibraryFileAdapter實施。

在這里，如上所述，我們可以輕松地交換我們的詩歌來源（文件，數(shù)據(jù)庫，網(wǎng)絡(luò)服務(wù)......）。因此，作為文件的源的實際實現(xiàn)是技術(shù)細(xì)節(jié)（也稱為技術(shù)實現(xiàn)細(xì)節(jié)）。

領(lǐng)域方面

在這種情況下，我們的核心業(yè)務(wù)是對用戶有價值的東西，就是閱讀詩歌的概念。我們可以使用PoetryReader類在代碼中實現(xiàn)這個概念

應(yīng)用→域交互

從業(yè)務(wù)角度來看，請求是來自控制臺應(yīng)用程序還是其他應(yīng)用程序無關(guān)緊要，這是我們希望能夠抽象的技術(shù)細(xì)節(jié)。這恰恰是最初的意圖之一：“由用戶和測試一起驅(qū)動”。因此，域中沒有控制臺的概念。然而，我們的應(yīng)用程序允許從用戶的角度（=它提供的服務(wù)）來請求詩歌。我們將在域中找到這一概念（由IRequestVerses實現(xiàn)），這將允許應(yīng)用程序端與域進(jìn)行交互。

域→基礎(chǔ)設(shè)施互動

同樣，從域的角度來看，詩歌是來自文件還是數(shù)據(jù)庫并不重要，我們希望能夠獨立于外部系統(tǒng)測試我們的應(yīng)用程序。域中沒有文件概念。要運(yùn)作，領(lǐng)域仍然需要得到詩歌。我們發(fā)現(xiàn)這個概念是以IObtainPoems界面的形式在Domain中獲取詩歌。正是這種獲取詩歌的概念將允許域與基礎(chǔ)設(shè)施方面進(jìn)行交互。

注意：從這里，當(dāng)您閱讀圖表時，您可以開始觀察顯示類之間關(guān)系的箭頭。實線箭頭表示調(diào)用或組合交互。沒有填充的箭頭表示繼承關(guān)系（如在UML中）。但不需要立即分析所有內(nèi)容，我們稍后會詳細(xì)探討。

注意：名稱IRequestVerses和IObtainPoems代表許多接口，我們將按照原則來討論它們。對于軼事，使用“i”啟動接口名稱的約定不再流行，但Thomas Pierrain將接口名稱作為第一人稱單數(shù)的句子讀取。IRequestVerses寫道：例如我請求經(jīng)文。我喜歡這個主意。

原則：依賴進(jìn)入內(nèi)部

這是實現(xiàn)目標(biāo)的基本原則。我們已經(jīng)開始在先前的原則中看到這一點。

Principle: Dependencies go to the Domain

程序可以通過控制臺和測試來控制，域中沒有控制臺的概念。域不依賴于應(yīng)用程序端，應(yīng)用程序端依賴于域。應(yīng)用程序端（ConsoleAdapter）依賴于詩請求的概念，IRequestVerses（它定義了用戶方面的通用“詩請求”機(jī)制）。

同樣，程序可以獨立于其外部系統(tǒng)進(jìn)行測試，Domain不依賴于Infrastructure方面，相反，它是依賴于Domain的Infrastructure方面，通過獲取詩歌的概念，IObtainPoems。從技術(shù)上講，基礎(chǔ)結(jié)構(gòu)方面的類將繼承Domain中定義的接口并實現(xiàn)它，我們將在下面詳細(xì)討論它以討論依賴性反轉(zhuǎn)。

內(nèi)在和外在

如果我們將依賴關(guān)系（<<>）視為箭頭，那么這個原則將中心域定義為內(nèi)部，將其他所有內(nèi)容定義為外部（見圖）。當(dāng)我們討論六邊形結(jié)構(gòu)時，我們經(jīng)常發(fā)現(xiàn)內(nèi)部和外部的這些概念。它甚至可以成為記憶和傳播的基本點：依賴關(guān)系進(jìn)入內(nèi)部。

換句話說，一切都取決于域，域不依賴于任何東西。Alistair Cockburn堅持內(nèi)部和外部的這種劃分，這比應(yīng)用和基礎(chǔ)設(shè)施之間的差異更能解決最初的問題。

原理：邊界與接口隔離

總而言之，應(yīng)用程序代碼通過業(yè)務(wù)代碼中定義的接口（此處為IRequestVerses）來驅(qū)動業(yè)務(wù)代碼。業(yè)務(wù)代碼通過業(yè)務(wù)代碼（IObtainPoems）中定義的接口驅(qū)動基礎(chǔ)架構(gòu)。這些接口充當(dāng)內(nèi)部和外部之間的顯式絕緣體。

隱喻：端口和適配器

六邊形體系結(jié)構(gòu)使用端口和適配器的比喻來表示內(nèi)部和外部之間的交互。圖像是域定義了端口，如果它們遵循端口定義的規(guī)范，則可以在其上交換連接所有類型的適配器。

例如，我們可以設(shè)想Domain的一個端口，我們將在單元測試期間連接硬編碼數(shù)據(jù)源，或者在集成測試中連接真實數(shù)據(jù)庫。只需在Infrastructure端編寫相應(yīng)的實現(xiàn)和適配器，Domain就不會受到此更改的影響。

由業(yè)務(wù)代碼定義的這些接口隔離并允許與外部世界的交互，這些接口是Ports＆Adapters隱喻的端口。注意：如前所述，端口由業(yè)務(wù)定義，因此它們位于內(nèi)部。

另一方面，適配器表示外部代碼在端口與應(yīng)用程序代碼或基礎(chǔ)結(jié)構(gòu)的其余部分之間形成粘合劑。這里，適配器分別是ConsoleAdapter和PoetryLibraryFileAdapter。這些適配器在外面。

另一個隱喻：六角形

正如我們在上圖中看到的那樣，另一個為這個架構(gòu)命名的比喻是六邊形。為什么是六邊形？主要原因是它是一個易于繪制的形狀，為圖表上的多個端口和適配器留出了空間。事實證明，即使六邊形最終是軼事，六邊形體系結(jié)構(gòu)的表達(dá)也比端口和適配器模式更受歡迎。可能是因為聽起來更好？

理論部分已經(jīng)結(jié)束，沒有其他原則：對于其他一切我們完全自由。