六邊形架構圖 (Hexagonal Architecture Diagram) 是一種用於軟體設計的架構模式，另一個名稱是 Port & Adapters Diagram，這個模型很常被領域驅動設計 DDD (Domain Driven Development) 一起討論，他是 DDD 的一種架構，但兩者性質不應該混為一談。

在解釋以下這張圖之前，先來看看下面這張圖 [1]:

慢慢細看，中間這一層放滿了 Adapter, 而六邊形外的全是服務、外部系統，六邊形的內部是 Domain (也就是完全內部系統)，上面還有 Port，顯然，這些外部服務會是由 Adapter 串接進入到服務內部，然後在透過 Domain 內部的 Port 進入業務邏輯。

則，可以看到圖片加上註解變成:

轉接器層上擁有的轉接器，理論意義上就是設計模式中的轉接器模式，為了不讓內部系統變成外部系統 API 的形狀，所以刻意加了一個 Adapter 來分離內外，有點像是在做軟硬整合時，你需要寫 Firmware 跟 Driver 來讓硬體跟軟體互通。

而內部系統的 Port 則可以是 Microservice 的服務 Port 或各種類型的軟體介面。

基於這個概念，以下就參考 [2] 製造一個可能的情境，主要是要做出轉接器模式達到內外部系統分離的架構:

最主要 Adapter 左側都是給終端 API 呼叫的，例如如果你自己寫了一個 Test Agent，或是租用 Runscope, Postman 之類的 API 測試服務，就通通走 Test Adapter 去處理測試與內部分離的工作，比方說 Test Agent 建立用戶工廠之類的功能，然後把資料帶入 Test Adapter 來測試行為。

其餘 Web 進來的模式可能有 REST API, GraphQL API 等形式，反正他們走進來都是 HTTP Protocol。

右側則都是內部所需的外部服務，依照左右區分的話，可以歸類左側屬於 API Interface ，是外部進入 Adapter 的主要入口，而右側屬於 SPI (Service Provider Interface)，也可想成 SDK 類的轉接層，像是資料庫使用 PostgreSQL, MySQL, SQLite 都需要一個 Driver (e.g: JDBC) 來讓你的程式可以跟目標服務溝通。

而如果要完全的區分兩邊用途的話，常見的看法是把左側的 API 區都是 Input (輸入)，而右側的 SPI 區都是 Output (輸出)，內部則分為轉接層、內部系統層 (你的應用程式)。

另外也有一種看法 [7] ，把左側 API 區看成應用區 (Application)，把右側 SPI 區看成基礎建設區 (Infrastructure)，中間則是領域模型跟商業邏輯。

References:
[1] https://online.visual-paradigm.com/knowledge/cloud-architecture-diagrams/what-is-hexagonal-architecture-diagram/
[2] https://www.gushiciku.cn/pl/gCCk/zh-hk
[3] https://chowdera.com/2021/08/20210816014828453t.html
[4] https://blog.csdn.net/chachapaofan/article/details/104170285
[5] 使用六邊形架構解耦技術代碼與業務邏輯
[6] https://www.jianshu.com/p/c2a361c2406c
[7] https://cloud.tencent.com/developer/article/1500287