DDD與微服務(wù)是可以相通的，其關(guān)鍵在于Bounded Context。

分布式系統(tǒng)的定義

在談?wù)撨@個(gè)之前，我們需要就什么是分布式系統(tǒng)達(dá)成一致。在我看來，判斷一個(gè)系統(tǒng)是否是分布式的，其標(biāo)準(zhǔn)是看系統(tǒng)中是否存在跨進(jìn)程通信。是進(jìn)程決定了協(xié)作與通信的方式，從而引申出兩種具有本質(zhì)區(qū)別的編程模型：

• 進(jìn)程內(nèi)編程模型
• 跨進(jìn)程編程模型

它們之間的區(qū)別在于組件之間的調(diào)用方式。進(jìn)程內(nèi)的組件調(diào)用是非常簡單的，就Java而言，各個(gè)駐留于同一個(gè)JVM的對象與變量都放在堆內(nèi)存或者棧內(nèi)存中，對象的調(diào)用(包括方法的調(diào)用)就是一種內(nèi)存的尋址。Java語言通過new關(guān)鍵字創(chuàng)建實(shí)例，從而獲得該實(shí)例的指針，以便于對該實(shí)例的屬性與方法進(jìn)行調(diào)用。

跨進(jìn)程組件之間的調(diào)用方式與進(jìn)程內(nèi)調(diào)用有著本質(zhì)的。雖然跨進(jìn)程通信機(jī)制存在各種不同的實(shí)現(xiàn)，但它們要考量的因素都是相同的，需要考慮：

• 進(jìn)程間的通信協(xié)議
• 如何尋址
• 消息的序列化與反序列化

除此之外，在資源管理、事務(wù)一致性以及部署方面，都會因?yàn)榭邕M(jìn)程通信的原因而產(chǎn)生巨大的差別。

顯然，跨進(jìn)程通信固有的復(fù)雜度帶來了編程模型的改變，但它能夠更加有效地利用硬件資源，卻是分布式系統(tǒng)的主要目標(biāo)。因此，在IT發(fā)展的當(dāng)前歷史背景下，我們將進(jìn)程作為邊界來定義分布式系統(tǒng)是非常有意義的。

說明：不同的語言平臺，進(jìn)程的概念有細(xì)微差別，通信機(jī)制自然也有所不同。Java進(jìn)程等同于操作系統(tǒng)的進(jìn)程，但Erlang與Go的進(jìn)程概念則不相同，要更加輕量級。

跨進(jìn)程組件之間的調(diào)用方式其實(shí)是對通信機(jī)制的一種抽象，它其實(shí)又包含了：

• 進(jìn)程間通信機(jī)制(如共享內(nèi)存、管道、Socket)
• 結(jié)構(gòu)化通信機(jī)制(如RPC)
• 中間件通信機(jī)制(分布式對象如CORBA、組件中間件如EJB、消息中間件、面向服務(wù)與REST)

討論C4模型的Container

Simon Brown提出了自己的C4模型，如下圖所示：

我們對Container的劃分，可以將進(jìn)程作為劃分的邊界，即我認(rèn)為的“物理邊界”。所以Container在架構(gòu)中除了可以作為邏輯視圖的組成元素之外，也可以視為物理視圖的一部分。

無獨(dú)有偶，Alistair Cockburn提出的六邊形架構(gòu)(又名port-adapter模式)在邊界含義上與Container是與之呼應(yīng)的。下圖中外部六邊形的邊界就是一個(gè)物理邊界，按照之前的分析，我們可以將其視為進(jìn)程邊界。

微服務(wù)與Bounded Context

微服務(wù)作為一個(gè)可以獨(dú)立部署的微小服務(wù)，天生就是一個(gè)在物理上隔離的自治服務(wù)。從物理視圖的角度看，一個(gè)微服務(wù)就是C4模型中的Container，也就是六邊形架構(gòu)中的六邊形。如果我們將六邊形架構(gòu)與DDD的Bounded Context對應(yīng)起來，那么就可以引入DDD的戰(zhàn)略設(shè)計(jì)來劃分服務(wù)邊界，從而幫助我們進(jìn)行微服務(wù)設(shè)計(jì)了。

一個(gè)典型的Bounded Context，可以具有自己的領(lǐng)域模型，訪問專有的數(shù)據(jù)庫，且可以引入“依賴注入”來滿足Uncle Bob所謂的Clean Architecture思想。下圖所示的Bounded Context的架構(gòu)，不正是可以表現(xiàn)為一個(gè)微服務(wù)嗎?

Context Map對微服務(wù)的闡釋

思考DDD中的Bounded Context，可以重點(diǎn)把握以下兩點(diǎn)：

• Bounded Context與Domain之間的關(guān)系
• Context Map

倘若我們認(rèn)為Bounded Context與Domain之間存在對應(yīng)關(guān)系，就說明可以從業(yè)務(wù)架構(gòu)的層面來設(shè)計(jì)微服務(wù)。通過用例、通用語言或者其他手段，都可以幫助我們識別Bounded Context，進(jìn)而得到相對合理的服務(wù)邊界。

若要判斷微服務(wù)的設(shè)計(jì)是否合理，則可以通過DDD的Context Map進(jìn)一步驗(yàn)證和判別Bounded Context的劃分，并理清楚它們之間的關(guān)系。

Eric Evans在DDD一書中列出了九種Context Map，基本上可以歸類為：

• 團(tuán)隊(duì)之間的協(xié)作方式
• 進(jìn)程之間的集成方式

為什么說Bounded Context之間的關(guān)系可以理解為是團(tuán)隊(duì)之間的協(xié)作方式呢?理論根據(jù)來自康威定律，即：

一個(gè)Bounded Context可能會映射到一個(gè)開發(fā)團(tuán)隊(duì)，所以討論Bounded Context之間的關(guān)系，也可以視為是討論團(tuán)隊(duì)之間的關(guān)系。至于進(jìn)程之間的集成方式，無論是引入ACL(防腐層)還是OHS(開放主機(jī)服務(wù))，目的都是在實(shí)現(xiàn)進(jìn)程間通信的同時(shí)，更好地做到Bounded Context之間的松散耦合。以微服務(wù)觀之，就是要滿足服務(wù)邊界足夠的自治性。

故而當(dāng)DDD遇到微服務(wù)，其實(shí)有許多玄妙的相似之處值得深究。它們之間或許可以碰撞出感情的火花，也未可知呢。

【本文為51CTO專欄作者“張逸”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文