指導我們寫出漂亮代碼有一種方式是學習設計模式，自從 Gof 四人組的《設計模式》出版后，各類設計模式的書層出不窮。熟讀這類書籍，對面試肯定是有幫助的，但代碼能力是否有大的長進就不一定了，如果沒能理解背后的思想，去生搬硬套，只會起反作用。
背后的思想就是指面向對象的原則：
- 單一職責原則（SRP）
- 開放封閉原則（OCP）
- 里氏替換原則（LSP）
- 接口隔離原則（ISP）
- 依賴倒置原則（DIP）
這些原則就是告訴我們應該怎么合理地組織類和方法。最終使我們開發的程序能夠滿足：可擴展、可復用、可閱讀。只是看這些原則比較抽象，最近又看了下六邊形架構，我認為對代碼的編寫有很好的指導作用，下面就聊聊六邊形架構。
什么是六邊形架構？
六邊形架構（Hexagonal Architecture），也被稱為端口與適配器架構（Ports and Adapters Architecture），是一種軟件架構模式，旨在實現高內聚、低耦合和可測試性的應用程序設計。該架構由 AlistAIr Cockburn 發明，他是敏捷宣言的簽署者之一。
從上圖可以看出有內外兩層六邊形，深藍色和淺藍色。
- 內層（深藍色）：負責領域內的業務邏輯，相對獨立，不用關注任何外部依賴或技術細節，也不用關心外部的客戶端和服務，我們定義為領域層。
- 外層（淺藍色）：負責獲取不同的業務域的數據，進行業務邏輯的組裝，并與外界進行交互，我們定義為應用層。
上圖中的紫色部分的 context 是我們在實踐過程中添加的，在應用層中進行邏輯組裝時，如果沒有業務上下文的概念，會導致很多方法被重復調用，所以在業務入口會進行上下文的初始化，將上下文貫穿整個調用鏈。
端口和適配器
六邊形架構也被稱為端口與適配器架構，端口和適配器是兩個非常關鍵且重要的概念。
端口
端口是應用程序定義的接口，必須由外界實現，以便應用程序可以接收或發送信息，進行解耦。這個接口是廣義的，不光是指 Interface，WebAPI 接口，一些類的公共方法也屬于接口的范疇。
端口有分為兩種：
- 入站端口：業務服務對外暴露的公有方法。
- 出站端口：出站端口只一組方法的接口定義，提供一種規范，供出站適配器來實現。
使用端口和適配器進行處理應用程序的輸入和輸出，端口只是一種抽象，是應用程序在不了解任何內容的情況下與外界交互的一種方式。
例如：如果想要進行數據庫的讀取和寫入，不是直接操作數據庫，而是在接口中定義讀取和寫入的方法。應用程序不需要知道數據來自哪里，需要寫到什么地方去，可能是數據庫，也可能是文件系統或緩存，甚至會同時進行操作。
適配器
適配器是連接應用程序核心和外部接口的橋梁。它負責將外部請求轉換為應用程序核心可以理解的格式，并將核心的響應轉換為外部接口可以接受的格式。
適配器也分為兩種：
- 入站適配器：通常就是對外的 RestAPI，通過調用入站端口來處理外部的請求，也可以是消息隊列的消費者，進行一些事件的監聽，來處理異步業務，當接收到消息時也是調用入站端口來進行處理。
- 出站適配器：出站適配器實現出站接口，調用外部的服務來實現一個完整的業務邏輯，出站適配器也可以是消息隊列的生產者。
當要將數據保存到數據庫中時，適配器從接口定義的數據格式中獲取數據，并將其轉換為可以寫入數據庫的內容，重要的是，無論在適配器中怎么變化，核心域和接口不會發生變化。這就非常有用，將應用程序的核心邏輯和外部存儲隔離開了。
正是由于端口和適配器的存在，程序變得穩定和容易變化。
為什么叫六邊形架構？
為什么叫六邊形架構？而不是三角形、圓形、正方形呢？
目前沒有明確的理由說明為什么是六邊形，而不是其他的形狀。或許只是因為六邊形比較好看。又或許，一個小的六邊形代表這一個模塊，一個系統有很多這種模塊組成，模塊之間有輸入輸出的交互，就像蜂窩一樣。
而蜂窩正好是六邊形的。
六邊形架構的特點
通過六邊形架構，應用程序核心成為了架構的中心，具有清晰的邊界和職責，可以獨立于外部接口進行測試和演進。外部接口和適配器負責處理與外部系統的交互，使應用程序核心保持獨立和可復用。主要有以下特點：
- 高內聚和低耦合：應用程序核心獨立于外部依賴，使得不同部分的修改不會對其他部分產生影響，提高了代碼的可維護性。
- 可測試性：應用程序核心可以輕松地進行單元測試，因為它不依賴于具體的外部接口或技術細節。
- 可擴展性：通過添加新的適配器，可以很容易地與新的外部系統進行集成，而不會對應用程序核心產生影響。
六邊形架構的原則
當我們談論六邊形架構時，會涉及到幾個核心原則。這些原則指導我們持續優化軟件架構，使系統保持其整體的穩定性。
- 分離關注點：六邊形架構將系統劃分為不同的層次，每個層次都有其特定的職責和關注點。這種分離使得每個組件可以專注于自身的任務，降低了耦合性，提高了模塊的可復用性和可測試性。
- 內外部分離：六邊形架構將系統劃分為內部和外部兩個六邊形，分別代表核心業務邏輯和外部接口。內部六邊形負責處理核心業務邏輯，而外部六邊形則負責處理業務整合和外部系統的交互。這種內外部分離的設計使得系統更容易擴展和適應變化。
- 依賴注入：六邊形架構鼓勵使用依賴注入來管理組件之間的依賴關系。通過依賴注入，組件的依賴關系可以在運行時進行配置，而不是在編譯時固定。這樣可以實現組件之間的松耦合，并且方便進行替換和測試。
- 接口驅動：六邊形架構強調基于接口編程，通過定義清晰的接口和協議來促進組件之間的通信。接口的使用讓各層之間解耦，又便于擴展。
- 測試驅動：六邊形架構鼓勵在開發過程中采用測試驅動開發（TDD）的方法。通過編寫測試用例來定義組件的行為，然后逐步實現和改進組件以滿足測試的要求。這種測試驅動的開發方法有助于保證系統的質量和穩定性。
根據這些原則，可以發現，這些就是在文章開頭提到的那些面向對象的原則，通過六邊形架構的包裝后，更具備實操性。
和 DDD 、微服務的關系
在網上查六邊形架構的資料，六邊形架構往往都跟 DDD 、微服務在一起被提及，但他們之間其實沒有很必然的聯系。
就像微服務和 DDD 一樣，也沒有必然聯系，因為：
- DDD 中子域和限界上下文的概念可以對應到微服務中的服務。
- 微服務中一個服務可以由一個團隊進行開發，DDD 的一個領域模型也是建議由一個獨立的團隊負責。
所以，微服務和領域驅動開發（DDD）常常會一起提及，在學習的時候，也會兩種一起學，互相配合能夠更好地落地。
如果說，微服務是架構風格、DDD 是架構設計方法、那么六邊形架構就是一種具體的指導編碼的架構實踐。
一些資料
VS 的 HexagonalX 擴展。
在 VS 中可以安裝六邊形架構的擴展，安裝后在創建項目時就會多出六邊形架構的項目類型可供選擇。
幾個 Github 上的示例項目和文章：
https://github.com/alesimoes/hexagonal-clean-architecture。
https://github.com/ivanpaulovich/clean-architecture-manga。
https://blog.allegro.tech/2020/05/hexagonal-architecture-by-example.html。
