六邊形架構：管理複雜性的解決方案

來源：小技術君

六邊形架構是一種將外部系統與核心應用程式分離的架構模式。

六邊形架構是什麼？

六邊形架構是一種架構模式，將外部系統與核心應用程式分隔開來。

其思想很簡單。我們從一個六邊形開始。然後應用埠和介面卡，對吧？

六邊形有六個邊。六邊形的形狀本身並沒有特別含義。它只是提供了一種清晰的方式來討論和解釋應用程式的埠、介面卡和領域。

這個形狀提供了一種解釋應用程式流程中小塊內容的方式，而不會讓觀眾對整個應用程式的圖景感到不知所措。它本質上限制了設計者一次只設計或解釋小塊容易理解的部分。

從內部開始

應用程式領域位於六邊形的內部。當我們說領域時，我們指的是遵循領域驅動設計（DDD）原則，並且我們的業務邏輯不會洩露到六邊形外部。為了上下文，DDD：

1.專注於透過定義與業務特定部分相關的模型來解決主要問題。2.使用所有團隊成員都能理解的通用語言。3.定義了一個邊界上下文，其中封裝了領域模型。

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

假設我們正在構建一個新的應用程式，允許使用者透過網站將檔案上傳到一箇中央儲存庫以供共享。

以下是一些基本的應用程式要求：

1.由經過身份驗證的使用者透過網站上傳檔案。2.檔案是為程式上傳的，或者換句話說是為了某個目的上傳的。3.程式/目的是一組預先配置的檔案規範，檔案必須符合這些規範。4.程式規則指定一些內容，比如：— 可以上傳的檔案型別— 欄位數量— 其他要求，比如加密或壓縮檔案— 檔案必須符合某些規範才能被接受。5.必須授權使用者以上傳特定程式的檔案。

返回領域

領域表示應用程式的關鍵業務邏輯，允許使用者將檔案上傳到儲存庫以供其他方共享。請注意，以下領域只涵蓋了上傳者、上傳者的授權和要上傳的檔案的檔案規格。

藍色矩形被稱為實體，它們連同藍色欄位一起表示滿足我們功能要求所需的結構。

一個更全面的領域模型可能包括已上傳或已下載檔案的下載者和檔案配置詳情，以及可能應用的資料質量配置。可以爭論說這可以進一步劃分為子領域，但為了簡潔起見，我們將堅持當前的示例。

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

眾所周知六邊形架構的原則之一是領域不洩露到六邊形外部，也不需要了解外部世界的任何資訊。

在這一點上，我們可以從理論上寫出滿足這個應用程式基本要求的程式碼，從業務邏輯功能的角度來看，這將是純粹的應用程式程式碼開發。然而，這並不能幫助我們太多，因為業務邏輯被包裝在六邊形的外邊界之內。

我們需要一些輸入和輸出，所以現在我們做一些關於我們如何與領域互動的假設。

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

1.資料以使用者的請求形式提交，可以是資訊請求或上傳檔案。（輸入）2.這些資料經過驗證、轉換並儲存在某個地方。（輸出）

我們需要與這個領域互動，以便它能夠完成其工作，即授權上傳者、接受檔案並檢查檔案規格（基於程式/目的）是否有效。

讓我們稍作停頓，因為上述兩個步驟提到了該架構的另一個好處。在這種純粹形式下，可以實現單元測試或測試驅動開發（TDD）。

編寫自動化單元測試可在開發過程中或進行增強時執行，可以減少引入錯誤的風險，提高程式碼質量，尤其是如果單元測試作為程式碼檢入和部署活動的一部分進行執行（考慮持續整合/持續交付）。

如果你在遵循TDD，你會先在程式碼中寫一個單元測試，然後再寫任何功能性程式碼。該測試將失敗，因為你尚未編寫任何功能性程式碼。然後，你編寫滿足測試的功能性程式碼。接著你編寫下一個測試，然後功能性程式碼，然後測試，依此類推。

這就是本文的全部內容。現在我們已經瞭解了什麼是六邊形架構，並建立了我們的領域模型，下一篇我們將探討如何連線埠和介面卡，使架構能夠開始管理複雜性。