六邊形架構(gòu)是一種將外部系統(tǒng)與核心應(yīng)用程序分離的架構(gòu)模式。

六邊形架構(gòu)是什么？

六邊形架構(gòu)是一種架構(gòu)模式，將外部系統(tǒng)與核心應(yīng)用程序分隔開來。

其思想很簡單。我們從一個(gè)六邊形開始。然后應(yīng)用端口和適配器，對吧？

六邊形有六個(gè)邊。六邊形的形狀本身并沒有特別含義。它只是提供了一種清晰的方式來討論和解釋應(yīng)用程序的端口、適配器和領(lǐng)域。

這個(gè)形狀提供了一種解釋應(yīng)用程序流程中小塊內(nèi)容的方式，而不會(huì)讓觀眾對整個(gè)應(yīng)用程序的圖景感到不知所措。它本質(zhì)上限制了設(shè)計(jì)者一次只設(shè)計(jì)或解釋小塊容易理解的部分。

從內(nèi)部開始

應(yīng)用程序領(lǐng)域位于六邊形的內(nèi)部。當(dāng)我們說領(lǐng)域時(shí)，我們指的是遵循領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）原則，并且我們的業(yè)務(wù)邏輯不會(huì)泄露到六邊形外部。為了上下文，DDD：

• 專注于通過定義與業(yè)務(wù)特定部分相關(guān)的模型來解決主要問題。
• 使用所有團(tuán)隊(duì)成員都能理解的通用語言。
• 定義了一個(gè)邊界上下文，其中封裝了領(lǐng)域模型。

遵循DDD原則，為了本文的目的，我使用以下過程提出了以下領(lǐng)域。

假設(shè)我們正在構(gòu)建一個(gè)新的應(yīng)用程序，允許用戶通過網(wǎng)站將文件上傳到一個(gè)中央存儲(chǔ)庫以供共享。

以下是一些基本的應(yīng)用程序要求：

• 由經(jīng)過身份驗(yàn)證的用戶通過網(wǎng)站上傳文件。
• 文件是為程序上傳的，或者換句話說是為了某個(gè)目的上傳的。
• 程序/目的是一組預(yù)先配置的文件規(guī)范，文件必須符合這些規(guī)范。
• 程序規(guī)則指定一些內(nèi)容，比如：— 可以上傳的文件類型— 字段數(shù)量— 其他要求，比如加密或壓縮文件— 文件必須符合某些規(guī)范才能被接受。
• 必須授權(quán)用戶以上傳特定程序的文件。

返回領(lǐng)域

領(lǐng)域表示應(yīng)用程序的關(guān)鍵業(yè)務(wù)邏輯，允許用戶將文件上傳到存儲(chǔ)庫以供其他方共享。請注意，以下領(lǐng)域只涵蓋了上傳者、上傳者的授權(quán)和要上傳的文件的文件規(guī)格。

藍(lán)色矩形被稱為實(shí)體，它們連同藍(lán)色字段一起表示滿足我們功能要求所需的結(jié)構(gòu)。

一個(gè)更全面的領(lǐng)域模型可能包括已上傳或已下載文件的下載者和文件配置詳情，以及可能應(yīng)用的數(shù)據(jù)質(zhì)量配置?？梢誀幷撜f這可以進(jìn)一步劃分為子領(lǐng)域，但為了簡潔起見，我們將堅(jiān)持當(dāng)前的示例。

從邏輯上講，我們的六邊形現(xiàn)在看起來像這樣：

眾所周知六邊形架構(gòu)的原則之一是領(lǐng)域不泄露到六邊形外部，也不需要了解外部世界的任何信息。

在這一點(diǎn)上，我們可以從理論上寫出滿足這個(gè)應(yīng)用程序基本要求的代碼，從業(yè)務(wù)邏輯功能的角度來看，這將是純粹的應(yīng)用程序代碼開發(fā)。然而，這并不能幫助我們太多，因?yàn)闃I(yè)務(wù)邏輯被包裝在六邊形的外邊界之內(nèi)。

我們需要一些輸入和輸出，所以現(xiàn)在我們做一些關(guān)于我們?nèi)绾闻c領(lǐng)域交互的假設(shè)。

在最簡單的形式下，這些假設(shè)聽起來像這樣：

• 數(shù)據(jù)以用戶的請求形式提交，可以是信息請求或上傳文件。（輸入）
• 這些數(shù)據(jù)經(jīng)過驗(yàn)證、轉(zhuǎn)換并存儲(chǔ)在某個(gè)地方。（輸出）

我們需要與這個(gè)領(lǐng)域交互，以便它能夠完成其工作，即授權(quán)上傳者、接受文件并檢查文件規(guī)格（基于程序/目的）是否有效。

讓我們稍作停頓，因?yàn)樯鲜鰞蓚€(gè)步驟提到了該架構(gòu)的另一個(gè)好處。在這種純粹形式下，可以實(shí)現(xiàn)單元測試或測試驅(qū)動(dòng)開發(fā)（TDD）。

編寫自動(dòng)化單元測試可在開發(fā)過程中或進(jìn)行增強(qiáng)時(shí)運(yùn)行，可以減少引入錯(cuò)誤的風(fēng)險(xiǎn)，提高代碼質(zhì)量，尤其是如果單元測試作為代碼檢入和部署活動(dòng)的一部分進(jìn)行運(yùn)行（考慮持續(xù)集成/持續(xù)交付）。

如果你在遵循TDD，你會(huì)先在代碼中寫一個(gè)單元測試，然后再寫任何功能性代碼。該測試將失敗，因?yàn)槟闵形淳帉懭魏喂δ苄源a。然后，你編寫滿足測試的功能性代碼。接著你編寫下一個(gè)測試，然后功能性代碼，然后測試，依此類推。

這就是本文的全部內(nèi)容?，F(xiàn)在我們已經(jīng)了解了什么是六邊形架構(gòu)，并創(chuàng)建了我們的領(lǐng)域模型，下一篇我們將探討如何連接端口和適配器，使架構(gòu)能夠開始管理復(fù)雜性。