六邊形架構是什么？
六邊形架構是一種架構模式，將外部系統與核心應用程序分隔開來。
其思想很簡單。我們從一個六邊形開始。然后應用端口和適配器，對吧？
六邊形有六個邊。六邊形的形狀本身并沒有特別含義。它只是提供了一種清晰的方式來討論和解釋應用程序的端口、適配器和領域。
這個形狀提供了一種解釋應用程序流程中小塊內容的方式，而不會讓觀眾對整個應用程序的圖景感到不知所措。它本質上限制了設計者一次只設計或解釋小塊容易理解的部分。
從內部開始
應用程序領域位于六邊形的內部。當我們說領域時，我們指的是遵循領域驅動設計（DDD）原則，并且我們的業務邏輯不會泄露到六邊形外部。為了上下文，DDD：
- 專注于通過定義與業務特定部分相關的模型來解決主要問題。
- 使用所有團隊成員都能理解的通用語言。
- 定義了一個邊界上下文，其中封裝了領域模型。
遵循DDD原則，為了本文的目的，我使用以下過程提出了以下領域。
假設我們正在構建一個新的應用程序，允許用戶通過網站將文件上傳到一個中央存儲庫以供共享。
以下是一些基本的應用程序要求：
- 由經過身份驗證的用戶通過網站上傳文件。
- 文件是為程序上傳的，或者換句話說是為了某個目的上傳的。
- 程序/目的是一組預先配置的文件規范，文件必須符合這些規范。
- 程序規則指定一些內容，比如：— 可以上傳的文件類型— 字段數量— 其他要求，比如加密或壓縮文件— 文件必須符合某些規范才能被接受。
- 必須授權用戶以上傳特定程序的文件。
返回領域
領域表示應用程序的關鍵業務邏輯，允許用戶將文件上傳到存儲庫以供其他方共享。請注意，以下領域只涵蓋了上傳者、上傳者的授權和要上傳的文件的文件規格。
藍色矩形被稱為實體，它們連同藍色字段一起表示滿足我們功能要求所需的結構。
一個更全面的領域模型可能包括已上傳或已下載文件的下載者和文件配置詳情，以及可能應用的數據質量配置。可以爭論說這可以進一步劃分為子領域，但為了簡潔起見，我們將堅持當前的示例。
從邏輯上講，我們的六邊形現在看起來像這樣：
眾所周知六邊形架構的原則之一是領域不泄露到六邊形外部，也不需要了解外部世界的任何信息。
在這一點上，我們可以從理論上寫出滿足這個應用程序基本要求的代碼，從業務邏輯功能的角度來看，這將是純粹的應用程序代碼開發。然而，這并不能幫助我們太多，因為業務邏輯被包裝在六邊形的外邊界之內。
我們需要一些輸入和輸出，所以現在我們做一些關于我們如何與領域交互的假設。
在最簡單的形式下，這些假設聽起來像這樣：
- 數據以用戶的請求形式提交，可以是信息請求或上傳文件。（輸入）
- 這些數據經過驗證、轉換并存儲在某個地方。（輸出）
我們需要與這個領域交互，以便它能夠完成其工作，即授權上傳者、接受文件并檢查文件規格（基于程序/目的）是否有效。
讓我們稍作停頓，因為上述兩個步驟提到了該架構的另一個好處。在這種純粹形式下，可以實現單元測試或測試驅動開發（TDD）。
編寫自動化單元測試可在開發過程中或進行增強時運行，可以減少引入錯誤的風險，提高代碼質量，尤其是如果單元測試作為代碼檢入和部署活動的一部分進行運行（考慮持續集成/持續交付）。
如果你在遵循TDD，你會先在代碼中寫一個單元測試，然后再寫任何功能性代碼。該測試將失敗，因為你尚未編寫任何功能性代碼。然后，你編寫滿足測試的功能性代碼。接著你編寫下一個測試，然后功能性代碼，然后測試，依此類推。
這就是本文的全部內容。現在我們已經了解了什么是六邊形架構，并創建了我們的領域模型，下一篇我們將探討如何連接端口和適配器，使架構能夠開始管理復雜性。
