指導(dǎo)我們寫出漂亮代碼有一種方式是學(xué)習(xí)設(shè)計(jì)模式，自從 Gof 四人組的《設(shè)計(jì)模式》出版后，各類設(shè)計(jì)模式的書層出不窮。熟讀這類書籍，對面試肯定是有幫助的，但代碼能力是否有大的長進(jìn)就不一定了，如果沒能理解背后的思想，去生搬硬套，只會起反作用。

背后的思想就是指面向?qū)ο蟮脑瓌t：

• 單一職責(zé)原則（SRP）
• 開放封閉原則（OCP）
• 里氏替換原則（LSP）
• 接口隔離原則（ISP）
• 依賴倒置原則（DIP）

這些原則就是告訴我們應(yīng)該怎么合理地組織類和方法。最終使我們開發(fā)的程序能夠滿足：可擴(kuò)展、可復(fù)用、可閱讀。只是看這些原則比較抽象，最近又看了下六邊形架構(gòu)，我認(rèn)為對代碼的編寫有很好的指導(dǎo)作用，下面就聊聊六邊形架構(gòu)。

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

六邊形架構(gòu)（Hexagonal Architecture），也被稱為端口與適配器架構(gòu)（Ports and Adapters Architecture），是一種軟件架構(gòu)模式，旨在實(shí)現(xiàn)高內(nèi)聚、低耦合和可測試性的應(yīng)用程序設(shè)計(jì)。該架構(gòu)由 Alistair Cockburn 發(fā)明，他是敏捷宣言的簽署者之一。

從上圖可以看出有內(nèi)外兩層六邊形，深藍(lán)色和淺藍(lán)色。

• 內(nèi)層（深藍(lán)色）：負(fù)責(zé)領(lǐng)域內(nèi)的業(yè)務(wù)邏輯，相對獨(dú)立，不用關(guān)注任何外部依賴或技術(shù)細(xì)節(jié)，也不用關(guān)心外部的客戶端和服務(wù)，我們定義為領(lǐng)域?qū)印?/li>
• 外層（淺藍(lán)色）：負(fù)責(zé)獲取不同的業(yè)務(wù)域的數(shù)據(jù)，進(jìn)行業(yè)務(wù)邏輯的組裝，并與外界進(jìn)行交互，我們定義為應(yīng)用層。

上圖中的紫色部分的 context 是我們在實(shí)踐過程中添加的，在應(yīng)用層中進(jìn)行邏輯組裝時(shí)，如果沒有業(yè)務(wù)上下文的概念，會導(dǎo)致很多方法被重復(fù)調(diào)用，所以在業(yè)務(wù)入口會進(jìn)行上下文的初始化，將上下文貫穿整個(gè)調(diào)用鏈。

端口和適配器

六邊形架構(gòu)也被稱為端口與適配器架構(gòu)，端口和適配器是兩個(gè)非常關(guān)鍵且重要的概念。

端口

端口是應(yīng)用程序定義的接口，必須由外界實(shí)現(xiàn)，以便應(yīng)用程序可以接收或發(fā)送信息，進(jìn)行解耦。這個(gè)接口是廣義的，不光是指 Interface，WebAPI 接口，一些類的公共方法也屬于接口的范疇。

端口有分為兩種：

• 入站端口：業(yè)務(wù)服務(wù)對外暴露的公有方法。
• 出站端口：出站端口只一組方法的接口定義，提供一種規(guī)范，供出站適配器來實(shí)現(xiàn)。

使用端口和適配器進(jìn)行處理應(yīng)用程序的輸入和輸出，端口只是一種抽象，是應(yīng)用程序在不了解任何內(nèi)容的情況下與外界交互的一種方式。

例如：如果想要進(jìn)行數(shù)據(jù)庫的讀取和寫入，不是直接操作數(shù)據(jù)庫，而是在接口中定義讀取和寫入的方法。應(yīng)用程序不需要知道數(shù)據(jù)來自哪里，需要寫到什么地方去，可能是數(shù)據(jù)庫，也可能是文件系統(tǒng)或緩存，甚至?xí)瑫r(shí)進(jìn)行操作。

適配器

適配器是連接應(yīng)用程序核心和外部接口的橋梁。它負(fù)責(zé)將外部請求轉(zhuǎn)換為應(yīng)用程序核心可以理解的格式，并將核心的響應(yīng)轉(zhuǎn)換為外部接口可以接受的格式。

適配器也分為兩種：

• 入站適配器：通常就是對外的 RestAPI，通過調(diào)用入站端口來處理外部的請求，也可以是消息隊(duì)列的消費(fèi)者，進(jìn)行一些事件的監(jiān)聽，來處理異步業(yè)務(wù)，當(dāng)接收到消息時(shí)也是調(diào)用入站端口來進(jìn)行處理。
• 出站適配器：出站適配器實(shí)現(xiàn)出站接口，調(diào)用外部的服務(wù)來實(shí)現(xiàn)一個(gè)完整的業(yè)務(wù)邏輯，出站適配器也可以是消息隊(duì)列的生產(chǎn)者。

當(dāng)要將數(shù)據(jù)保存到數(shù)據(jù)庫中時(shí)，適配器從接口定義的數(shù)據(jù)格式中獲取數(shù)據(jù)，并將其轉(zhuǎn)換為可以寫入數(shù)據(jù)庫的內(nèi)容，重要的是，無論在適配器中怎么變化，核心域和接口不會發(fā)生變化。這就非常有用，將應(yīng)用程序的核心邏輯和外部存儲隔離開了。

正是由于端口和適配器的存在，程序變得穩(wěn)定和容易變化。

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

為什么叫六邊形架構(gòu)？而不是三角形、圓形、正方形呢？

目前沒有明確的理由說明為什么是六邊形，而不是其他的形狀?；蛟S只是因?yàn)榱呅伪容^好看。又或許，一個(gè)小的六邊形代表這一個(gè)模塊，一個(gè)系統(tǒng)有很多這種模塊組成，模塊之間有輸入輸出的交互，就像蜂窩一樣。

而蜂窩正好是六邊形的。

六邊形架構(gòu)的特點(diǎn)

通過六邊形架構(gòu)，應(yīng)用程序核心成為了架構(gòu)的中心，具有清晰的邊界和職責(zé)，可以獨(dú)立于外部接口進(jìn)行測試和演進(jìn)。外部接口和適配器負(fù)責(zé)處理與外部系統(tǒng)的交互，使應(yīng)用程序核心保持獨(dú)立和可復(fù)用。主要有以下特點(diǎn)：

• 高內(nèi)聚和低耦合：應(yīng)用程序核心獨(dú)立于外部依賴，使得不同部分的修改不會對其他部分產(chǎn)生影響，提高了代碼的可維護(hù)性。
• 可測試性：應(yīng)用程序核心可以輕松地進(jìn)行單元測試，因?yàn)樗灰蕾囉诰唧w的外部接口或技術(shù)細(xì)節(jié)。
• 可擴(kuò)展性：通過添加新的適配器，可以很容易地與新的外部系統(tǒng)進(jìn)行集成，而不會對應(yīng)用程序核心產(chǎn)生影響。

六邊形架構(gòu)的原則

當(dāng)我們談?wù)摿呅渭軜?gòu)時(shí)，會涉及到幾個(gè)核心原則。這些原則指導(dǎo)我們持續(xù)優(yōu)化軟件架構(gòu)，使系統(tǒng)保持其整體的穩(wěn)定性。

• 分離關(guān)注點(diǎn)：六邊形架構(gòu)將系統(tǒng)劃分為不同的層次，每個(gè)層次都有其特定的職責(zé)和關(guān)注點(diǎn)。這種分離使得每個(gè)組件可以專注于自身的任務(wù)，降低了耦合性，提高了模塊的可復(fù)用性和可測試性。
• 內(nèi)外部分離：六邊形架構(gòu)將系統(tǒng)劃分為內(nèi)部和外部兩個(gè)六邊形，分別代表核心業(yè)務(wù)邏輯和外部接口。內(nèi)部六邊形負(fù)責(zé)處理核心業(yè)務(wù)邏輯，而外部六邊形則負(fù)責(zé)處理業(yè)務(wù)整合和外部系統(tǒng)的交互。這種內(nèi)外部分離的設(shè)計(jì)使得系統(tǒng)更容易擴(kuò)展和適應(yīng)變化。
• 依賴注入：六邊形架構(gòu)鼓勵(lì)使用依賴注入來管理組件之間的依賴關(guān)系。通過依賴注入，組件的依賴關(guān)系可以在運(yùn)行時(shí)進(jìn)行配置，而不是在編譯時(shí)固定。這樣可以實(shí)現(xiàn)組件之間的松耦合，并且方便進(jìn)行替換和測試。
• 接口驅(qū)動(dòng)：六邊形架構(gòu)強(qiáng)調(diào)基于接口編程，通過定義清晰的接口和協(xié)議來促進(jìn)組件之間的通信。接口的使用讓各層之間解耦，又便于擴(kuò)展。
• 測試驅(qū)動(dòng)：六邊形架構(gòu)鼓勵(lì)在開發(fā)過程中采用測試驅(qū)動(dòng)開發(fā)（TDD）的方法。通過編寫測試用例來定義組件的行為，然后逐步實(shí)現(xiàn)和改進(jìn)組件以滿足測試的要求。這種測試驅(qū)動(dòng)的開發(fā)方法有助于保證系統(tǒng)的質(zhì)量和穩(wěn)定性。

根據(jù)這些原則，可以發(fā)現(xiàn)，這些就是在文章開頭提到的那些面向?qū)ο蟮脑瓌t，通過六邊形架構(gòu)的包裝后，更具備實(shí)操性。

和 DDD 、微服務(wù)的關(guān)系

在網(wǎng)上查六邊形架構(gòu)的資料，六邊形架構(gòu)往往都跟 DDD 、微服務(wù)在一起被提及，但他們之間其實(shí)沒有很必然的聯(lián)系。

就像微服務(wù)和 DDD 一樣，也沒有必然聯(lián)系，因?yàn)椋?/p>

• DDD 中子域和限界上下文的概念可以對應(yīng)到微服務(wù)中的服務(wù)。
• 微服務(wù)中一個(gè)服務(wù)可以由一個(gè)團(tuán)隊(duì)進(jìn)行開發(fā)，DDD 的一個(gè)領(lǐng)域模型也是建議由一個(gè)獨(dú)立的團(tuán)隊(duì)負(fù)責(zé)。

所以，微服務(wù)和領(lǐng)域驅(qū)動(dòng)開發(fā)（DDD）常常會一起提及，在學(xué)習(xí)的時(shí)候，也會兩種一起學(xué)，互相配合能夠更好地落地。

如果說，微服務(wù)是架構(gòu)風(fēng)格、DDD 是架構(gòu)設(shè)計(jì)方法、那么六邊形架構(gòu)就是一種具體的指導(dǎo)編碼的架構(gòu)實(shí)踐。

一些資料

VS 的 HexagonalX 擴(kuò)展。

在 VS 中可以安裝六邊形架構(gòu)的擴(kuò)展，安裝后在創(chuàng)建項(xiàng)目時(shí)就會多出六邊形架構(gòu)的項(xiàng)目類型可供選擇。

幾個(gè) GitHub 上的示例項(xiàng)目和文章：

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。