領(lǐng)域?qū)訉崿F(xiàn)面向領(lǐng)域模型，實現(xiàn)領(lǐng)域模型的核心業(yè)務(wù)邏輯，屬于原子模型，它需要保持領(lǐng)域模型和

業(yè)務(wù)邏輯的穩(wěn)定，對外提供穩(wěn)定的細(xì)粒度的領(lǐng)域服務(wù)，所以它處于架構(gòu)的核心位置。

應(yīng)用層實現(xiàn)面向用戶操作相關(guān)的用例和流程，對外提供粗粒度的API服務(wù)。

可以說，這三種架構(gòu)都考慮了前端需求的變與領(lǐng)域模型的不變。

總體來說，不管前端如何變化，在企業(yè)沒有大的變革的情況下，核心領(lǐng)域邏輯基本不會大變，所以

領(lǐng)域模型相對穩(wěn)定，而用例和流程則會隨著外部應(yīng)用需求而隨時調(diào)整。把握好這個規(guī)律，我們就知

道該如何設(shè)計應(yīng)用層和領(lǐng)域?qū)恿恕?/p>

架構(gòu)模型通過分層的方式來控制需求變化從外到里對系統(tǒng)的影響，從外向里受需求影響逐步減小。

這樣設(shè)計的好處很明顯了，就是可以保證領(lǐng)域?qū)拥暮诵臉I(yè)務(wù)邏輯不會因為外部需求和流程的變動而

調(diào)整，對于建立前臺靈活、中臺穩(wěn)固的架構(gòu)很有幫助。

中臺和微服務(wù)設(shè)計的關(guān)鍵：領(lǐng)域模型和微服務(wù)的合理分層設(shè)計。

5、從三種架構(gòu)模型看中臺和微服務(wù)設(shè)計

中臺本質(zhì)上是領(lǐng)域的子域，它可能是核心域，也可能是通用域或支撐域。通常大家認(rèn)為阿里的中臺

對應(yīng)DDD的通用域，將通用的公共能力沉淀為中臺，對外提供通用共享服務(wù)。

中臺作為子域還可以繼續(xù)分解為子子域，在子域分解到合適大小，通過事件風(fēng)暴劃分限界上下文以

后，就可以定義微服務(wù)了，微服務(wù)用來實現(xiàn)中臺的能力。表面上看，DDD、中臺、微服務(wù)這三者

之間似乎沒什么關(guān)聯(lián)，實際上它們的關(guān)系是非常緊密的，組合在一起可以作為一個理論體系用于你

的中臺和微服務(wù)設(shè)計。

5.1 中臺建設(shè)要聚焦領(lǐng)域模型

中臺需要站在全企業(yè)的高度，考慮能力的共享和復(fù)用。

中臺設(shè)計時，我們需要建立中臺內(nèi)所有限界上下文的領(lǐng)域模型，DDD 建模過程中會考慮架構(gòu)演進(jìn)

和功能的重新組合。領(lǐng)域模型建立的過程會對業(yè)務(wù)和應(yīng)用進(jìn)行清晰的邏輯和物理邊界（微服務(wù)）劃

分。領(lǐng)域模型的結(jié)果會影響到后續(xù)的系統(tǒng)模型、架構(gòu)模型和代碼模型，最終影響到微服務(wù)的拆分和

項目落地。

因此，在中臺設(shè)計中我們首先要聚焦領(lǐng)域模型，將它放在核心位置。

5.2 微服務(wù)要有合理的架構(gòu)分層

微服務(wù)設(shè)計要有分層的設(shè)計思想，讓各層各司其職，建立松耦合的層間關(guān)系。

不要把與領(lǐng)域無關(guān)的邏輯放在領(lǐng)域?qū)訉崿F(xiàn)，保證領(lǐng)域?qū)拥募儩嵑皖I(lǐng)域邏輯的穩(wěn)定，避免污染領(lǐng)域模

型。也不要把領(lǐng)域模型的業(yè)務(wù)邏輯放在應(yīng)用層，這樣會導(dǎo)致應(yīng)用層過于龐大，最終領(lǐng)域模型會失

焦。如果實在無法避免，我們可以

引入防腐層，進(jìn)行新老系統(tǒng)的適配和轉(zhuǎn)換，過渡期完成后，可以直接將防腐層代碼拋棄。

有的微服務(wù)可以與前端應(yīng)用集成，一起完成特定的業(yè)務(wù)，這是項目級微服務(wù)。而有的則是某個職責(zé)

單一的中臺微服務(wù)，企業(yè)級的業(yè)務(wù)流程需要將多個這樣的微服務(wù)組合起來才能完成，這是企業(yè)級中

臺微服務(wù)。兩類微服務(wù)由于復(fù)雜度不一樣，集成方式也會有差異。

5.2.1 項目級微服務(wù)

項目級微服務(wù)的內(nèi)部，遵循分層架構(gòu)模型就可以了。

領(lǐng)域模型的核心邏輯在領(lǐng)域?qū)訉崿F(xiàn)，服務(wù)的組合和編排在應(yīng)用層實現(xiàn)，通過API網(wǎng)關(guān)為前臺應(yīng)用提

供服務(wù)，實現(xiàn)前后端分離。但項目級的微服務(wù)，可能會調(diào)用其它微服務(wù)。通常項目級微服務(wù)之間的

集成，發(fā)生在微服務(wù)的應(yīng)用層，由應(yīng)用服務(wù)調(diào)用其它微服務(wù)發(fā)布在API網(wǎng)關(guān)上的應(yīng)用服務(wù)。

它除了可以組合和編排自己的領(lǐng)域服務(wù)外，還可以組合和編排外部微服務(wù)的應(yīng)用服務(wù)。它只要將編

排后的服務(wù)發(fā)布到API網(wǎng)關(guān)供前端調(diào)用，這樣前端就可以直接訪問自己的微服務(wù)了。

5.2.2 企業(yè)級中臺微服務(wù)

企業(yè)級的業(yè)務(wù)流程，往往是多個中臺微服務(wù)一起協(xié)作完成的。

企業(yè)級中臺微服務(wù)的集成不能像項目級微服務(wù)一樣，在某一個微服務(wù)內(nèi)完成跨微服務(wù)的服務(wù)組合和

編排。

我們可以在中臺微服務(wù)之上增加一層，增加的這一層它的主要職能就是處理跨中臺微服務(wù)的服務(wù)組

合和編排，以及微服務(wù)之間的協(xié)調(diào)，它還可以完成前端不同渠道應(yīng)用的適配。如果再將它的業(yè)務(wù)范

圍擴(kuò)大一些，我可以將它做成一個面向不同行業(yè)和渠道的服務(wù)平臺。

我們借用BFF（服務(wù)于前端的后端，Backend for Frontends）這個詞，暫且稱它為BFF 微服務(wù)。

BFF微服務(wù)與其它微服務(wù)存在較大的差異，就是它沒有領(lǐng)域模型，因此這個微服務(wù)內(nèi)也不會有領(lǐng)域

層。BFF微服務(wù)可以承擔(dān)應(yīng)用層和用戶接口層的主要職能，完成各個中臺微服務(wù)的服務(wù)組合和編

排，可以適配不同前端和渠道的要求。

5.3 應(yīng)用和資源的解耦與適配

傳統(tǒng)以數(shù)據(jù)為中心的設(shè)計模式，應(yīng)用會對數(shù)據(jù)庫、緩存、文件系統(tǒng)等基礎(chǔ)資源產(chǎn)生嚴(yán)重依賴。

正是由于它們之間的這種強(qiáng)依賴的關(guān)系，我們一旦更換基礎(chǔ)資源就會對應(yīng)用產(chǎn)生很大的影響，因此

需要為應(yīng)用和資源解耦。

在微服務(wù)架構(gòu)中，應(yīng)用層、領(lǐng)域?qū)雍突A(chǔ)層解耦是通過倉儲模式，采用依賴倒置的設(shè)計方法來實現(xiàn)

的。在應(yīng)用設(shè)計中，我們會同步考慮和基礎(chǔ)資源的代碼適配，那么一旦基礎(chǔ)設(shè)施資源出現(xiàn)變更（比

如換數(shù)據(jù)庫），就可以屏蔽資源變更對業(yè)務(wù)代碼的影響，切斷業(yè)務(wù)邏輯對基礎(chǔ)資源的依賴，最終降

低資源變更對應(yīng)用的影響。

6、總結(jié)

DDD分層架構(gòu)、整潔架構(gòu)、六邊形架構(gòu)都是以領(lǐng)域模型為核心，實行分層架構(gòu)，內(nèi)部核心業(yè)務(wù)邏

輯與外部應(yīng)用、資源隔離并解耦。請務(wù)必記好這個設(shè)計思想，今后會有大用處。