DDD的核心價值在於指導劃分限界上下文。不是所有限界上下文都採用領域驅動方式，非核心子域可參考資料驅動下的面向過程程式設計。限界上下文之內可以自由選擇架構模式，如MVC、分層架構、CQRS、六邊形架構、洋蔥架構等，如圖所示。

六邊形架構（Hexagonal Architecture）

在六邊形架構風格中，外部客戶和內部系統的互動都會透過埠和介面卡完成轉換，這些外部客戶之間是平等的，比如使用者web介面和資料庫持久化，當你需要一個新的外部客戶時，只需要增加相應的介面卡，比如當我們依賴外部一個RPC的服務時，只需要編寫對應的介面卡即可。

當將web介面和持久化統稱在一起，沒有前端和資料庫後端之分的時候，相信你也不得不佩服這種角度不同的設計。

六邊形每條不同的邊代表了不同型別的埠，埠要麼處理輸入，要麼處理輸出。對於每種外界型別，都有一個介面卡與之對應，外界透過應用層API與內部進行互動。

上圖中有客戶請求使用了Http協議介面卡、微服務協議介面卡，還有一個請求使用了訊息介面卡（比如RabbitMQ、Kafka等）。埠並沒有明確的定義，它是一個非常靈活的概念。無論採用哪種方式對埠進行劃分，當客戶請求到達時，都應該有相應的介面卡對輸入進行轉化，然後埠將呼叫應用程式的某個操作或者嚮應用程式傳送一個事件，控制權由此交給內部區域。

應用程式透過公共API接收客戶請求，使用領域模型來處理請求。我們可以將DDD戰術設計的建模元素Repository的實現看作是持久化介面卡，該介面卡用於訪問先前儲存的聚合例項或者儲存新的聚合例項。正如圖中的介面卡DB Repository、Cache Repository、Mock Repository，我們可以使用不同的方式實現資源庫，比如關係型資料庫MySQL、快取Redis、甚至Mock儲存等。

如果應用程式向外界傳送領域事件訊息，我們將使用MQ介面卡進行處理。該介面卡處理訊息輸出，而上面提到的處理訊息的介面卡則是處理訊息輸入的，因此應該使用不同的埠。

一個典型的六邊形架構應用有兩個埠，一個埠對應使用者介面層，用於應用控制；一個對應資料訪問層，用於資料獲取和持久化。

架構目標：

獨立於框架與資料庫分離可測試性與外部結構分離與UI分離

架構原則：

關注點分離，切割不同層依賴原則：外部依賴內部，依賴倒置架構設計圍繞用例

其他DDD程式碼模型架構相關文章：