DDD、SOA、微服務和微內核，看到經常有人把這幾個概念拿出來一起講。事實上，DDD和其他三個不是一個維度的東西。

DDD其實特別好理解，DDD就是領域來驅動設計嘛，是一種設計思想。很容易又和OOA、OOD和OOP來比較了。這個回頭再說。

SOA、微服務和微內核都是架構風格，DDD里能和他們三個放在一起比較的是四層架構和六邊形架構。

四層架構

四層架構長這樣：

圖片

分為用戶接口層、應用層、領域層和基礎層，四層架構目的是為了解耦，下層不依賴上層，從依賴關系上講，四層架構的箭頭是反過來的。

目前這個架構，在現代系統中，通常用作項目工程模塊的設計。就是說更傳統的MVC逐漸被淘汰，目前主流就是這種四層架構。有的項目工程會先用限界上下文劃分子域，再用四層架構。然后代碼結構長這樣：

├─interfaces   API接口層
│   ├─dto     視圖模型,數據模型定義 vo/dto（大多數情況是一樣的）
│   └─controller   控制器，對外提供（Restful）接口
│ 
├─application   應用層
│   ├─service  應用服務，非核心服務 
│   └─***      others
│ 
├─domain   領域層
│   ├─entity        領域實體、聚合根，充血的領域模型 
│   ├─valueobject        領域值對象       
│   └─service  領域服務類，一些不能歸屬某個具體領域模型的行為
│ 
├─infrastructure  基礎設施層
│   ├─po           持久化對象 
│   ├─repository 倉儲類，持久化接口&實現，可與ORM映射框架結合
│   ├─dao         數據訪問對象 
│   ├─client       feign等調用客戶端 
└─  └─factory    工廠類，負責復雜領域對象創建，封裝細節

底層實體采用充血模型，有一些聚合，形成聚合根。與存儲層的交互封裝在倉庫中，用DDD工廠來管理倉庫。上層會將實體轉換成貧血模型再暴露出去。你們項目的結構，架構師是不是這樣定義的？

六邊形架構

六邊形架構很多文章作者把這個架構分成幾層，這些都是加上了作者個人的理解。實際上六邊形架構又叫洋蔥形架構很簡單，就是個端口適配器模式。外六邊形是技術域，內六邊形是業務域。這個常用于一些整體架構中。比如說基于一些基礎組件做二次開發。真正的業務實現是組件實現的，有一些專門的維護人員。但是團隊中往往會有更多成員在做封裝接口暴露給公司內的用戶，做高可用或者自動化運維這些通常所說的外層。這個外層就是六邊形架構里技術域解決的問題。

圖片

SOA和微服務架構

SOA的出現是為了解決功能復用的問題，將一些共通的模塊提取出來做成服務。這個我之前在開發中發現不好用，僅次于單體應用時各個模塊引入一個common的jar包。因為這些共通的模塊很可能適應不了各方面的需求，上層的需求總有一些差異。這樣的情況下，這個共通模塊就不太好維護了。

服務化的概念使得上世紀就已經產生的DDD得到了大家的關注。因為DDD解決了怎么服務化的問題，就是劃分領域。微服務就是服務化之后劃分粒度的問題了。

微內核架構

微內核架構又叫插件化架構，包含兩類組件：核心系統（core system）和插件模塊（plug-in modules）。核心系統負責和業務無關的通用功能，例如模塊加載、模塊間通信等；插件模塊負責實現具體的業務邏輯，例如“學生信息管理”系統中的“手機號注冊”功能。

核心系統（Core System）功能一般比較穩定，不會由于業務擴展而不斷修改，插件模塊需要根據業務功能的發展不斷地擴展。微內核的架構本質是將變化部分封裝在插件里，從而實現快速靈活擴展的目標，而同時又不影響整體系統的穩定。常見的例子有：Eclipse IDE、Spring、Dubbo。

我做過一個配置化項目。把業務流程劃分成模塊，會不斷有新業務接入進來，很多模塊都可以復用。比如業務A需要a\b\c三個模塊，業務B需要a\c\d\e四個模塊，那新業務進來只需要進行模塊流程的配置。如果需要的模塊沒有，那就以插件的形式集成進來再進行配置。我們稱這個服務采用的是微內核架構，目的就是要讓大家把新功能的開發做插件式開發，避免對舊功能的影響，提高系統的穩定性。