2.2.2 業務架構設計

應用DDD設計的系統，可以采用傳統的分層架構來實現，也可以采用六邊形架構和CQRS讀寫分離架構來實現。

1.分層架構

（1）接口層

統一處理系統對外的服務接口，可以是直接查詢，也可以是三方系統對接。

（2）應用層

調用各個領域完成一個具體的業務流程應用，不關心具體的業務實現，例如完成旅客購買機票這個行為，需要旅客和機票兩個領域參與。

（3）領域層

實際完成業務邏輯處理的地方，包含領域模型和領域服務，無須關心顯示及存儲等相關問題。

（4）基礎設施層

提供底層支撐功能，包括持久化、序列化與反序列化、消息中間件等。

這種分層架構與我們熟悉的MVC分層架構大同小異，是很容易從傳統分層過渡到DDD分層的架構設計。DDD分層架構如圖2-5所示。

2.六邊形架構

為六邊形架構如圖2-6所示。六邊形架構可以理解為“去結構化”的架構，系統內部與外界的交互過程通過適配器來完成，沒有層次，所有交互雙方只知道適配器的存在，不用知曉對方的存在。內部是核心業務邏輯，外部是基礎支撐或者其他交互系統。這種架構的好處是顯而易見的，一方面是解耦，另一方面是方便外部統一驅動、測試內部程序。例如與REST接口交互，使用REST適配器；與SOAP系統交互，使用SOAP適配器；與消息系統交互，使用消息適配器等。

3.CQRS讀寫分離架構

CQRS讀寫分離架構如圖2-7所示。向左的箭頭是Command線，向右的箭頭是Query線。

圖2-7中為了方便把讀寫進程畫在了一起，讀寫的數據庫也集中在一個數據庫。實際上讀寫完全可以是兩套系統，讀庫和寫庫也可以完全隔離。讀庫和寫庫的同步問題通常采取消息事件機制來解決，也可以監聽數據庫的binlog類的日志來完成同步。

實際生產中，筆者推薦將上述三種架構做一個融合，各取所長。架構整體上是六邊形架構，去中心化，讀寫必須分離，最后在各微服務領域內，采用DDD分層結構來組織業務流程及代碼。最終架構圖如圖2-8所示。

隨著業務越來越多元化，越來越復雜，對信息平臺的要求也越來越高。系統自然也由簡單走向復雜，由單體走向集群。在架構后續的演進中，組件化和服務化幾乎就成了一條必經之路。