六邊形架構（端口適配器）指南 - 8thlight
端口和適配器是一種架構模式，旨在將您的應用程序與細節解耦。
我的經驗證實了這一說法。在最近的一個項目中，我們的團隊決定從端口和適配器架構開始，隨著我們團隊的成長，它得到了回報。我們的團隊正在構建一些需要集成的服務。端口和適配器讓我們可以進行一些集成，并將我們的域模型與我們的數據庫模式分離，這為我們的團隊提供了靈活性，并將我們的應用程序與這些細節隔離開來。
但這是有代價的。我們的架構選擇意味著加入我們項目的人們面臨著學習曲線。大多數人不熟悉這種模式。或者可能聽說過，但還沒有實踐經驗。
我自己理解端口和適配器的道路是曲折的。我在網上看到很多用六邊形來可視化模式的圖表，但很難找到一個具體的例子來幫助我形成自己的心智模型。
如果您有類似的經歷并放棄了，或者目前正在嘗試理解端口和適配器，我提供這篇文章：
分層架構
要理解端口和適配器，我認為將其與更常見的 Web 應用程序架構模式（如分層架構）一起查看會很有幫助。MVC模式的控制器與您的業務邏輯交互，而業務邏輯與數據庫交互。這是一個很好的模式。它很簡單，它可以讓您快速啟動和運行！但分層架構可能并不總是最合適的。例如，在我們的項目中，分層架構對于新手來說可能更容易上手，但我們會失去敏捷性。
端口和適配器
端口和適配器就像一個分層的架構，但是它插入了端口來反轉依賴的方向。它在您的控制器和您的應用程序之間插入端口，也就是在您的應用和您的數據庫的適配器或稱ORM 之間。
一個 端口 是操作系統端口的隱喻。在這個例子中， 一個端口就是一個接口。
圖中的端口是紅色和黃色框。這里的顏色差異是有意的，因為有兩種端口： 傳入端口和 傳出端口。
傳入端口將是您的應用程序實現的接口 。出站端口是您的應用程序所依賴的接口 。“傳入”和“傳出”是我們團隊采用的術語。“驅動端口”和“驅動端口”是您可能會在其他文獻中找到的術語。
這給我們留下了適配器。就像端口一樣，有兩種適配器：傳入，用藍色表示；和外向，以紫色表示。這里的區別是傳入適配器 取決于傳入端口，傳出適配器 實現傳出端口。
端口和適配器不僅適用于 Web 框架。傳入適配器和傳出適配器不限于由控制器和數據庫適配器來實現。它們可以通過任何類型的適配器來實現。
例如，命令行接口可以滿足您的傳入適配器，而 HTTP 客戶端可以滿足您的傳出端口。我的示例僅描述了傳入和傳出端的一個適配器和端口，但您可以根據需要擁有多個！
示例應用
讓我們看一個受SmallerWebHexagon啟發的具體示例，Alistair Cockburn 關于端口和適配器的博客文章中引用 了該示例 。
假設我們有一個 Web 應用程序，它將接受一個數字并對其應用一個比率。我根據每個組件在端口和適配器圖中的作用對組件進行了顏色編碼。
組件分解如下：
- RatingUseCase 是一個傳入端口。它是RatingApplication 將實現 的接口， KtorHttpAdapter 將依賴于它。
- RatingApplication 圖中的對應于“應用程序使用案例”。這是我們關鍵業務邏輯所在的地方。這可以說是最重要的組件，它不受我們使用的 Web 框架或 ORM 等細節的影響。
- RatingProvider 黃色是我們的輸出端口。這是應用程序獲取正確速率所依賴的抽象，也是傳出適配器將實現的接口。
- InCodeRater 是即將離任的適配器。它實現 RatingProvider 接口并獲取應用程序的費率。想象一下，我們需要從文件或數據庫中獲取此速率的未來。我們可以添加此行為而無需修改我們的核心應用程序！
- KtorHttpAdapter 是輸入適配器。它取決于傳入端口，它將通過其構造函數接受它。這是將驅動我們的應用程序的適配器。
- 最后，還有 main 配置 RatingApplication with InCodeRater 和 KtorHttpAdapter with RatingApplication 并啟動服務器的功能。
