DDD戰(zhàn)術(shù)篇：領(lǐng)域模型的應(yīng)用
領(lǐng)域驅(qū)動設(shè)計DDD在戰(zhàn)術(shù)建模(后文簡稱建模，除非特別說明)上提供了一個元模型體系(如下圖)，通過這個元模型我們會對戰(zhàn)略建模過程中識別出來的問題子域進行抽象，而通過抽象來指導(dǎo)***的落地實現(xiàn)。
(DDD構(gòu)建的元模型元素腦圖)
這里我們談的戰(zhàn)術(shù)階段實際就是這樣一個抽象過程。這個抽象過程由于元模型的存在實際是一定程度模式化的。這樣的好處是并非只能技術(shù)人員參與建模，業(yè)務(wù)人員經(jīng)過一定的培訓(xùn)也是完全可以理解的。在帶領(lǐng)不少團隊實踐建模的過程中，業(yè)務(wù)人員參與戰(zhàn)術(shù)設(shè)計也是我要求的。
由于已經(jīng)有不少書籍介紹DDD的元模型，這里我們就不再贅述，轉(zhuǎn)而談?wù)勥@個抽象過程中大家經(jīng)常遇到的一些困惑。這些比較常見的問題可能是DDD元模型未來演進需要解決的，但我們?nèi)匀灰⒁鈽I(yè)務(wù)問題和架構(gòu)設(shè)計的多樣性，不要過度規(guī)范，以至于過猶不及。
業(yè)務(wù)對象的抽象
通過對業(yè)務(wù)問題的子域劃分，我們找到了一些關(guān)鍵的業(yè)務(wù)對象。在開始進行抽象前一個必須的步驟就是“講故事”!
講什么故事呢?關(guān)于這個子域解決的業(yè)務(wù)問題或者提供的業(yè)務(wù)能力的故事。既然是故事，就必須有清晰的業(yè)務(wù)場景和業(yè)務(wù)對象之間的交互。這件事情看起來是如此自然和簡單，然則一個團隊里能夠站起來有條不紊陳述清楚的卻沒有幾人。讀到這里的讀者不妨停下來試試，你是否能夠把現(xiàn)在你所做的業(yè)務(wù)在兩三分鐘內(nèi)場景化地描述出來?
這么做顯然目的是讓我們能夠比較完整地思考我們所要提煉和抽象的業(yè)務(wù)對象有哪些。只有當(dāng)我們能夠“講”清楚業(yè)務(wù)場景的時候，才應(yīng)該開始抽象的步驟。對于一個業(yè)務(wù)對象，我們常見的抽象可以是“實體”(Entity)和“值對象”(Value Object)。
這兩個抽象方式在定義上的區(qū)別是，實體需要給予一個唯一標(biāo)識，而值對象不需要(可以通過屬性集合標(biāo)識)。當(dāng)然另外一個經(jīng)常引用的區(qū)別是，實體應(yīng)該是有一個連續(xù)的生命周期的，比如我們在一個訂單跟蹤領(lǐng)域里抽象訂單為一個實體，那么每個訂單應(yīng)該有一個唯一識別號，訂單也應(yīng)該有從下單創(chuàng)建到***交貨完成的生命周期。
顯然，如果不增加其它約束條件，值對象的抽象是沒有意義的，都用實體不就行了?但如果我們稍微思考一下一個實體的管理成本，比如需要保證生命周期中實體狀態(tài)的一致性，那么我們就會發(fā)現(xiàn)值對象變得很簡單很可愛。當(dāng)一個對象在我們(抽象)的世界里不能改變的時候，一切都變得簡單了，這個對象被創(chuàng)建后只能被引用，當(dāng)沒有引用時我們可以把它交給垃圾回收自動處理。
隨著高并發(fā)、分布式系統(tǒng)的普及，實際上我們在對業(yè)務(wù)對象抽象的***步思考是能否用值對象。如果大家實現(xiàn)的技術(shù)架構(gòu)采用函數(shù)范式的語言(類似Closure)，那么首先考慮值對象抽象可能就是一個建模原則了。
對象抽象初步完成后，一定要再重復(fù)一次之前的故事來審視一下我們的建模。經(jīng)歷這個抽象過程后，參與討論的每個人都應(yīng)該發(fā)現(xiàn)自己更清晰業(yè)務(wù)的需求和需要提供的能力了。
聚合的封裝
DDD元模型中一個核心概念叫“聚合”(Aggregate)。這個從建筑學(xué)來的名詞非常形象，建筑學(xué)上我們翻譯為“骨料”，是形成混凝土的重要元素，也是為什么混凝土如此堅固的基礎(chǔ)。
(混凝土里的一種骨料)
同理，在DDD建模中，聚合也是我們構(gòu)建領(lǐng)域模型的基礎(chǔ)，并且每個聚合都是內(nèi)聚性很高的組合。聚合本身完成了我們對骨干業(yè)務(wù)規(guī)則的封裝，減小了我們實現(xiàn)過程中出錯的可能。
以上面那個訂單跟蹤領(lǐng)域為例，假設(shè)我們允許一個訂單下存在多個子訂單，而每個子訂單也是可以獨立配送的，這種情況下我們抽象出“子訂單”這個實體。顯然訂單和子訂單存在業(yè)務(wù)邏輯上的一致性，沒有訂單的時候不應(yīng)該創(chuàng)建子訂單，更新子訂單的時候應(yīng)該同時“通知”所屬的訂單。這個時候如果采用把訂單和子訂單聚合起來的封裝就很有必要了。
采用聚合抽象的結(jié)果就是訪問每個子訂單都需要從相關(guān)的訂單入口(i.e., 訂單為聚合根)，存取時我們都是以這個聚合為基本單位，即包含了訂單和訂單下面的所有子訂單。顯然這樣的好處是在訂單跟蹤這個領(lǐng)域模型里，訂單作為一個聚合存在，我們只需要一次性梳理清楚訂單和子訂單的邏輯關(guān)系，就不需要在未來每次引用時都考慮這里面的業(yè)務(wù)規(guī)則了。
(訂單跟蹤領(lǐng)域的訂單聚合)
在建模過程中，很多團隊并沒有努力思考聚合的存在。封裝這個在技術(shù)實現(xiàn)領(lǐng)域的基本原則在建模時卻很少被重視起來。開篇提到在戰(zhàn)術(shù)建模過程中強調(diào)業(yè)務(wù)領(lǐng)域人員的參與也是為了解決這個問題，聚合的識別實際是針對業(yè)務(wù)規(guī)則的封裝，當(dāng)我們不理解業(yè)務(wù)規(guī)則的時候是無法做出是否封裝的判斷的。
一言以蔽之，識別聚合是認(rèn)知潛在核心業(yè)務(wù)規(guī)則的過程，而定義出來的聚合是在大家共識基礎(chǔ)上對核心業(yè)務(wù)規(guī)則的封裝。
領(lǐng)域服務(wù)的定義
在最初的元模型定義里，領(lǐng)域服務(wù)讓不少人糾結(jié)，一個經(jīng)典的例子是在賬戶管理領(lǐng)域里對“轉(zhuǎn)賬”這個業(yè)務(wù)行為的抽象。由于轉(zhuǎn)賬本身是作用在至少兩個賬戶上的，所以把轉(zhuǎn)賬作為一個賬戶的行為顯然是不合適的。那么如果我們把轉(zhuǎn)賬名詞化抽象成一個實體呢?感覺也是比較別扭，畢竟轉(zhuǎn)賬是依附于賬戶存在的。
這個時候DDD在元模型里提出了服務(wù)(Service)這個抽象，轉(zhuǎn)賬被抽象為一個服務(wù)感覺就順暢多了。同樣道理，在我們上面的訂單跟蹤領(lǐng)域里，如果跟蹤的過程中需要進行短信的通知，一個比較好的建模就是抽象出一個“通知”服務(wù)來完成。
我經(jīng)常會用靜態(tài)方法來幫助技術(shù)人員理解服務(wù)的抽象(雖然服務(wù)并不一定用靜態(tài)方法來實現(xiàn))。服務(wù)本身就像一個靜態(tài)方法一樣，擁有一定的邏輯但不持有任何的信息，從整個領(lǐng)域來看也不存在不同“版本”的同一個服務(wù)。
一個經(jīng)常困擾大家的問題是對Service這個詞語的限定，有的分層架構(gòu)設(shè)計里會出現(xiàn)領(lǐng)域服務(wù)(Domain Service)和應(yīng)用服務(wù)(Applicaiton Service)。大多數(shù)時候應(yīng)用服務(wù)在領(lǐng)域服務(wù)的上層，直接對外部提供接口。如果存在這樣的分層，那么領(lǐng)域服務(wù)就不應(yīng)該直接對外，而應(yīng)該通過應(yīng)用服務(wù)。
舉個例子，前面的訂單消息通知如果是一個領(lǐng)域服務(wù)，在完成訂單狀態(tài)變化時創(chuàng)建通知消息，而***的通知以短信的方式發(fā)給設(shè)定的人群，這樣就應(yīng)該有一個相應(yīng)的應(yīng)用服務(wù)，包含了具體的業(yè)務(wù)場景處理邏輯。之后也可能有一個郵件通知的應(yīng)用服務(wù)，同樣調(diào)用了這個通知領(lǐng)域服務(wù)，但通過郵件渠道來完成最終的業(yè)務(wù)場景。
由于微服務(wù)架構(gòu)的流行，每個子領(lǐng)域的粒度已經(jīng)相當(dāng)細了，很多時候已經(jīng)沒有這樣的領(lǐng)域服務(wù)和應(yīng)用服務(wù)的區(qū)分了。當(dāng)然從簡單性角度出發(fā)這是好事情。在整個建模過程中，服務(wù)的抽象往往是最不確定的，也是最值得大家反復(fù)斟酌的地方。
Repositories的使用
Repositories是一個非常容易被誤解的抽象，很多人會直接聯(lián)想到具體的數(shù)據(jù)存儲。在初期采用DDD建模的時候，我經(jīng)?？桃饣乇苓@個抽象，避免讓大家陷入思考紊亂。
這個抽象概念實際可以追溯到Martin Fowler的Object Query模式。另外一個相關(guān)概念是DAO(Data Access Object)，都是用來簡化需要存儲的數(shù)據(jù)和對應(yīng)的業(yè)務(wù)對象之間的映射關(guān)系。不同的是Repositories針對更加粗顆粒度的抽象，在DDD這個方法里我們可以認(rèn)為映射對象是我們的聚合。針對每個實體在實現(xiàn)時候也可能創(chuàng)造出對應(yīng)的DAO(比如采用Hibernate這樣的ORM框架)，但顯然在建模過程中不是我們需要關(guān)注的。
那么Repositories的抽象為什么是必要的呢?讓我們再回到訂單跟蹤這個例子，通知訂單狀態(tài)發(fā)生變化的服務(wù)在發(fā)出通知前，需要定位到訂單的信息(可能包括訂單的相關(guān)干系人和子訂單的信息)。通知作為一個服務(wù)是不應(yīng)該持有具體訂單信息的，這個時候我們就需要通過Repositories的抽象來建立對訂單這個聚合的查詢，即有一個訂單的repo，而具體的查詢邏輯應(yīng)該在這個repo中。
這樣的抽象在需要存儲和查詢值對象的時候也是必要的。假設(shè)我們分析訂單查詢這個領(lǐng)域，在這個領(lǐng)域里訂單記錄顯然已經(jīng)不允許修改了，自然的抽象方式就是值對象。同時一個查詢的服務(wù)來持有具體的查詢邏輯(比如按時間或用戶)是合理的。外部應(yīng)用直接調(diào)取了查詢服務(wù)(接口)并給出規(guī)定的參數(shù)，我們就需要一個訂單記錄的repo來持有跟存儲相關(guān)的查詢邏輯。當(dāng)然這并不是說有一個查詢就一定有一個repo與之對應(yīng)，如果查詢的邏輯非常簡單，未嘗不可以讓服務(wù)直接針對數(shù)據(jù)存儲實現(xiàn)。記住我們抽象的目標(biāo)是讓建模更簡單，抽象過程中應(yīng)該保持靈活。
限界上下文的意義
經(jīng)過最近10多年的演進，我們在如何支撐一個組織的規(guī)模化上達成了一些基本的共識。我們知道微服務(wù)架構(gòu)(Microservices)能夠幫助我們把成百上千的工程師們組織起來，而小團隊的自組織性是至關(guān)重要的。我們也逐步就如何能夠在技術(shù)和業(yè)務(wù)團隊之間明確溝通“架構(gòu)”這個難題上找到了DDD。那么DDD和微服務(wù)架構(gòu)的關(guān)系是什么呢?很多人會提到限界上下文(Bounded Context)。
我曾經(jīng)就這個話題專門撰文一篇(DDD&Microservices)。一個限界上下文封裝了一個相對獨立子領(lǐng)域的領(lǐng)域模型和服務(wù)。限界上下文地圖描述了各個子領(lǐng)域之間的集成調(diào)用關(guān)系。這個定義某種意義上和我們的微服務(wù)劃分不謀而合：以提供業(yè)務(wù)能力為導(dǎo)向的、自治的、獨立部署單元。所以雖然我們不能***依據(jù)限界上下文劃分服務(wù)，但限界上下文，或者說是DDD，絕對是我們設(shè)計微服務(wù)架構(gòu)的重要方法之一。
如果我們再追溯到DDD的戰(zhàn)略設(shè)計，我們會發(fā)現(xiàn)在問題域上，DDD通過子問題域(subdomain)的劃分就已經(jīng)進行了針對業(yè)務(wù)能力的分解，而限界上下文在解決方案域中完成了進一步分解。當(dāng)然我們不能完全認(rèn)為子問題域和限界上下文有嚴(yán)格意義上的一對一關(guān)系，但大多數(shù)情況下一個子問題域是會被設(shè)計成一個或多個限界上下文的。子域subdomain和限界上下文某種意義上是互相印證的，重點在區(qū)分問題域和解決方案域，這是落地DDD最困難的地方，也是判斷一個架構(gòu)師能力進階的分水嶺。
戰(zhàn)術(shù)建模小結(jié)
DDD的建模元素比較簡潔，本文中敘述的元模型應(yīng)該是滿足了大多數(shù)場景下的建模。毛主席曾經(jīng)有一句名言“戰(zhàn)略上要藐視敵人 戰(zhàn)術(shù)上要重視敵人”，就架構(gòu)設(shè)計來說我們沒有敵人，業(yè)務(wù)需求是我們的朋友。所以在領(lǐng)域驅(qū)動的架構(gòu)設(shè)計方面，咱們需要的是“戰(zhàn)略上要重視朋友，戰(zhàn)術(shù)上要簡化建模”。希望這句話能夠幫助正在實踐DDD的團隊重新思考自己在戰(zhàn)略問題域的投入和重視程度，不要揮舞著戰(zhàn)術(shù)模型的大錘到處尋找實際不存在的釘子。
【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】
