DDD、SOA、微服務(wù)和微內(nèi)核，看到經(jīng)常有人把這幾個(gè)概念拿出來(lái)一起講。事實(shí)上，DDD和其他三個(gè)不是一個(gè)維度的東西。

DDD其實(shí)特別好理解，DDD就是領(lǐng)域來(lái)驅(qū)動(dòng)設(shè)計(jì)嘛，是一種設(shè)計(jì)思想。很容易又和OOA、OOD和OOP來(lái)比較了。這個(gè)回頭再說(shuō)。

SOA、微服務(wù)和微內(nèi)核都是架構(gòu)風(fēng)格，DDD里能和他們?nèi)齻€(gè)放在一起比較的是四層架構(gòu)和六邊形架構(gòu)。

四層架構(gòu)

四層架構(gòu)長(zhǎng)這樣：

圖片

分為用戶接口層、應(yīng)用層、領(lǐng)域?qū)雍突A(chǔ)層，四層架構(gòu)目的是為了解耦，下層不依賴上層，從依賴關(guān)系上講，四層架構(gòu)的箭頭是反過(guò)來(lái)的。

目前這個(gè)架構(gòu)，在現(xiàn)代系統(tǒng)中，通常用作項(xiàng)目工程模塊的設(shè)計(jì)。就是說(shuō)更傳統(tǒng)的MVC逐漸被淘汰，目前主流就是這種四層架構(gòu)。有的項(xiàng)目工程會(huì)先用限界上下文劃分子域，再用四層架構(gòu)。然后代碼結(jié)構(gòu)長(zhǎng)這樣：

├─interfaces   API接口層
│   ├─dto     視圖模型,數(shù)據(jù)模型定義 vo/dto（大多數(shù)情況是一樣的）
│   └─controller   控制器，對(duì)外提供（Restful）接口
│ 
├─application   應(yīng)用層
│   ├─service  應(yīng)用服務(wù)，非核心服務(wù) 
│   └─***      others
│ 
├─domain   領(lǐng)域?qū)?│   ├─entity        領(lǐng)域?qū)嶓w、聚合根，充血的領(lǐng)域模型 
│   ├─valueobject        領(lǐng)域值對(duì)象       
│   └─service  領(lǐng)域服務(wù)類，一些不能歸屬某個(gè)具體領(lǐng)域模型的行為
│ 
├─infrastructure  基礎(chǔ)設(shè)施層
│   ├─po           持久化對(duì)象 
│   ├─repository 倉(cāng)儲(chǔ)類，持久化接口&實(shí)現(xiàn)，可與ORM映射框架結(jié)合
│   ├─dao         數(shù)據(jù)訪問(wèn)對(duì)象 
│   ├─client       feign等調(diào)用客戶端 
└─  └─factory    工廠類，負(fù)責(zé)復(fù)雜領(lǐng)域?qū)ο髣?chuàng)建，封裝細(xì)節(jié)

底層實(shí)體采用充血模型，有一些聚合，形成聚合根。與存儲(chǔ)層的交互封裝在倉(cāng)庫(kù)中，用DDD工廠來(lái)管理倉(cāng)庫(kù)。上層會(huì)將實(shí)體轉(zhuǎn)換成貧血模型再暴露出去。你們項(xiàng)目的結(jié)構(gòu)，架構(gòu)師是不是這樣定義的？

六邊形架構(gòu)

六邊形架構(gòu)很多文章作者把這個(gè)架構(gòu)分成幾層，這些都是加上了作者個(gè)人的理解。實(shí)際上六邊形架構(gòu)又叫洋蔥形架構(gòu)很簡(jiǎn)單，就是個(gè)端口適配器模式。外六邊形是技術(shù)域，內(nèi)六邊形是業(yè)務(wù)域。這個(gè)常用于一些整體架構(gòu)中。比如說(shuō)基于一些基礎(chǔ)組件做二次開(kāi)發(fā)。真正的業(yè)務(wù)實(shí)現(xiàn)是組件實(shí)現(xiàn)的，有一些專門(mén)的維護(hù)人員。但是團(tuán)隊(duì)中往往會(huì)有更多成員在做封裝接口暴露給公司內(nèi)的用戶，做高可用或者自動(dòng)化運(yùn)維這些通常所說(shuō)的外層。這個(gè)外層就是六邊形架構(gòu)里技術(shù)域解決的問(wèn)題。

圖片

SOA和微服務(wù)架構(gòu)

SOA的出現(xiàn)是為了解決功能復(fù)用的問(wèn)題，將一些共通的模塊提取出來(lái)做成服務(wù)。這個(gè)我之前在開(kāi)發(fā)中發(fā)現(xiàn)不好用，僅次于單體應(yīng)用時(shí)各個(gè)模塊引入一個(gè)common的jar包。因?yàn)檫@些共通的模塊很可能適應(yīng)不了各方面的需求，上層的需求總有一些差異。這樣的情況下，這個(gè)共通模塊就不太好維護(hù)了。

服務(wù)化的概念使得上世紀(jì)就已經(jīng)產(chǎn)生的DDD得到了大家的關(guān)注。因?yàn)镈DD解決了怎么服務(wù)化的問(wèn)題，就是劃分領(lǐng)域。微服務(wù)就是服務(wù)化之后劃分粒度的問(wèn)題了。

微內(nèi)核架構(gòu)

微內(nèi)核架構(gòu)又叫插件化架構(gòu)，包含兩類組件：核心系統(tǒng)（core system）和插件模塊（plug-in modules）。核心系統(tǒng)負(fù)責(zé)和業(yè)務(wù)無(wú)關(guān)的通用功能，例如模塊加載、模塊間通信等；插件模塊負(fù)責(zé)實(shí)現(xiàn)具體的業(yè)務(wù)邏輯，例如“學(xué)生信息管理”系統(tǒng)中的“手機(jī)號(hào)注冊(cè)”功能。

核心系統(tǒng)（Core System）功能一般比較穩(wěn)定，不會(huì)由于業(yè)務(wù)擴(kuò)展而不斷修改，插件模塊需要根據(jù)業(yè)務(wù)功能的發(fā)展不斷地?cái)U(kuò)展。微內(nèi)核的架構(gòu)本質(zhì)是將變化部分封裝在插件里，從而實(shí)現(xiàn)快速靈活擴(kuò)展的目標(biāo)，而同時(shí)又不影響整體系統(tǒng)的穩(wěn)定。常見(jiàn)的例子有：Eclipse IDE、Spring、Dubbo。

我做過(guò)一個(gè)配置化項(xiàng)目。把業(yè)務(wù)流程劃分成模塊，會(huì)不斷有新業(yè)務(wù)接入進(jìn)來(lái)，很多模塊都可以復(fù)用。比如業(yè)務(wù)A需要a\b\c三個(gè)模塊，業(yè)務(wù)B需要a\c\d\e四個(gè)模塊，那新業(yè)務(wù)進(jìn)來(lái)只需要進(jìn)行模塊流程的配置。如果需要的模塊沒(méi)有，那就以插件的形式集成進(jìn)來(lái)再進(jìn)行配置。我們稱這個(gè)服務(wù)采用的是微內(nèi)核架構(gòu)，目的就是要讓大家把新功能的開(kāi)發(fā)做插件式開(kāi)發(fā)，避免對(duì)舊功能的影響，提高系統(tǒng)的穩(wěn)定性。