[[422545]]

本文轉(zhuǎn)載自微信公眾號(hào)「牧小農(nóng)」，作者牧小農(nóng)。轉(zhuǎn)載本文請(qǐng)聯(lián)系牧小農(nóng)公眾號(hào)。

一、前言

最近公司一場(chǎng)有關(guān)于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的技術(shù)分享會(huì)，主要講解了服務(wù)的劃分，Restful API的設(shè)計(jì)，如何將抽象具有統(tǒng)一業(yè)務(wù)的范疇的Model，使其模塊化，同時(shí)能夠提煉組合多個(gè)模塊，使得業(yè)務(wù)能夠獨(dú)立服務(wù)化，在軟件開發(fā)中如何降低系統(tǒng)的復(fù)雜度是一個(gè)永恒的挑戰(zhàn)，在之前都是通過一系列的設(shè)計(jì)模式或者范例來降低一些比較常見的復(fù)雜度，這些都是通過技術(shù)手段來解決技術(shù)問題，沒有從根本上解決業(yè)務(wù)上的問題，但是在03年 Eric Evans 的《Domain Driven Design》 中，才是真正的從業(yè)務(wù)的角度出發(fā)，并且提供了一整套的針對(duì)純業(yè)務(wù)開發(fā)的架構(gòu)思路。為了更加深入理解，看了不少資料后，對(duì)DDD有了一點(diǎn)小小的個(gè)人心得，所以整理了一下，分享出來，希望能夠?qū)Υ蠹矣袔椭?/p>

二、什么是DDD

DDD 是 Eric Evans 在2003年出版的書名，同時(shí)也是這個(gè)架構(gòu)設(shè)計(jì)方法名的起源。Eric Evans “領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)之父”，世界杰出軟件建模專家。他創(chuàng)建的 “Domain Language” 公司，就是致力幫助公司機(jī)構(gòu)創(chuàng)建與業(yè)務(wù)緊密相關(guān)的軟件。

DDD 不是一套架構(gòu)，而是一種架構(gòu)思想，所以導(dǎo)致在代碼層面缺乏了足夠的約束，因此 DDD 在實(shí)際應(yīng)用中上手門檻比較高，而且在絕大部分公司中實(shí)際應(yīng)用中是沒有應(yīng)用到的，或者說只是應(yīng)用到了 DDD 部分思想 比如：建模的思想，對(duì)整個(gè)架構(gòu)體系的思想是無法落地的，而且一些依然火熱的ORM工具(Hibernate)助長(zhǎng)了貧血模型的擴(kuò)散，同樣因?yàn)閭鹘y(tǒng)的基于數(shù)據(jù)庫(kù)技術(shù)以及MVC的四成架構(gòu)應(yīng)用(UI、Business、Data Access、Database)依然能夠?yàn)槲覀兘鉀Q絕大部分的應(yīng)用開發(fā)。

之前的服務(wù)架構(gòu) 局限于單機(jī) +LB 用MVC提供的Rest接口提供外部服務(wù)調(diào)用，或者用WebService 做RPC調(diào)用，到了2014年，SOA開始火熱起來了，微服務(wù)開始如雨后春筍一樣的開始冒頭，怎么把一個(gè)應(yīng)用或者項(xiàng)目合理化的進(jìn)行拆分多個(gè)微服務(wù)，成為了各個(gè)技術(shù)負(fù)責(zé)人的思考的重點(diǎn)，而在DDD里面的 Bounded Context(限界上下文)中就為我們提供了一整套合理的架構(gòu)思想。

但是 DDD 可以讓我們思考 在我們的項(xiàng)目中哪些是可以被服務(wù)化拆分，哪些業(yè)務(wù)邏輯需要被聚合在一起，實(shí)現(xiàn)最小的開發(fā)和維護(hù)成本。

三、領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)-基本概念

DDD 的全稱為 Domain Driven Design，即領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)，DDD不是架構(gòu)，而是一種方法論(Methodology)，微服務(wù)架構(gòu)從一出來就沒有很好的理論支撐如何合理的劃分服務(wù)邊界。

在我們?cè)缙诔Ｒ姷能浖_發(fā)就是拿到產(chǎn)品需求后，先考慮數(shù)據(jù)庫(kù)設(shè)計(jì)，根據(jù)數(shù)據(jù)庫(kù)設(shè)計(jì)，建立對(duì)應(yīng)的實(shí)體層、服務(wù)層等等，但是這種方式會(huì)將 分析、設(shè)計(jì)和業(yè)務(wù)需求脫節(jié)，而更多的是直接考慮應(yīng)該如何實(shí)現(xiàn)，這就有點(diǎn)本末倒置了，而DDD 是從問題本身出發(fā)進(jìn)行的設(shè)計(jì)方法。

概念： 系統(tǒng)設(shè)計(jì)應(yīng)該是一種以領(lǐng)域?yàn)楹诵牡脑O(shè)計(jì)和開發(fā)，設(shè)計(jì)應(yīng)該通過維護(hù)一個(gè)深度反應(yīng)領(lǐng)域概念的模型，以及提供可行的經(jīng)過實(shí)踐校驗(yàn)的大量模式來應(yīng)對(duì)領(lǐng)域的復(fù)雜性。

DDD 更像小顆粒的迭代設(shè)計(jì)，最小單元是 領(lǐng)域模型(DomainModel)

什么是領(lǐng)域(Domain)?

什么是領(lǐng)域?比如我們經(jīng)常使用的某寶、某東、屬于網(wǎng)上電商領(lǐng)域，那么這些領(lǐng)域就會(huì)有對(duì)應(yīng)的商品瀏覽、購(gòu)物車、下單、扣減庫(kù)存、供應(yīng)商、付款等等核心環(huán)境。再比如我們想做一個(gè)聊天系統(tǒng)，那這個(gè)系統(tǒng)的核心業(yè)務(wù)就要確定，比如有 聯(lián)系人、分組、朋友圈、視頻、聊天記錄等功能。

所以，我們可以得知，一個(gè)領(lǐng)域的本質(zhì)上可以理解為一個(gè)問題域，只要是同一個(gè)領(lǐng)域的，那么他們 一定會(huì)有相同的問題域，因此只要我們確定了系統(tǒng)所屬的領(lǐng)域，那這個(gè)系統(tǒng)的核心業(yè)務(wù)，也就是我們要解決的關(guān)鍵問題，問題的范圍邊界也就基本確定了。

什么是設(shè)計(jì)(Design)?

DDD 中的設(shè)計(jì)主要是指領(lǐng)域模型的設(shè)計(jì)，為什么說是領(lǐng)域模型的設(shè)計(jì)而不是架構(gòu)設(shè)計(jì)或者其他的設(shè)計(jì)?因?yàn)镈DD是一種基于模型驅(qū)動(dòng)開發(fā)的軟件開發(fā)思想，強(qiáng)調(diào)領(lǐng)域模型是這個(gè)系統(tǒng)的核心，領(lǐng)域模型也是整個(gè)系統(tǒng)的核心價(jià)值所在，每一個(gè)領(lǐng)域，都有對(duì)應(yīng)的領(lǐng)域模型，因?yàn)轭I(lǐng)域模型能夠很好的幫助我們解決復(fù)雜的業(yè)務(wù)問題。領(lǐng)域模型綁定了領(lǐng)域和代碼的是吸納，確保了最終的代碼實(shí)現(xiàn)就一定是解決了領(lǐng)域中的核心問題，

四、四色原型建模

簡(jiǎn)單描述：

某個(gè)人(Party)的角色(PartyRole)在某個(gè)地點(diǎn)(Place)的角色(PlaceRole)用某個(gè)東西(Thing)的角色(ThingRole)做了某件事情(MomentInterval)

PartPlaceThing：簡(jiǎn)稱PPT，用淡綠色表示，常見的PPT有：部門、崗位、人員、地點(diǎn)、物品等。

Description：簡(jiǎn)稱Des，用淡藍(lán)色表示，主要用來對(duì)PPT進(jìn)行描述，常見的Des有：部門類型、崗位層級(jí)、人員類型、地點(diǎn)區(qū)域、物品分類等。

Role：用淡黃色表示，主要表示PPT在某個(gè)場(chǎng)景下扮演的角色，常見的角色有：財(cái)務(wù)類部門、管理類崗位、請(qǐng)假者、銷售點(diǎn)、產(chǎn)品等。

MomentInterval：簡(jiǎn)稱MI，用淡紅色表示，主要表示在一刻或一段時(shí)間內(nèi)發(fā)生的一件事情，常見的MI有：部門移動(dòng)、崗位移動(dòng)、員工離職、產(chǎn)品銷售等。

MomentInteval：簡(jiǎn)稱MIDetail，用淡紅色表示，主要表示MI的明細(xì)。

五、分層架構(gòu)

分層架構(gòu)是將軟件模塊按照水平切分的方式分成多個(gè)層

最基本的是分層架構(gòu)是三層：即表現(xiàn)層，領(lǐng)域?qū)雍蛿?shù)據(jù)持久層

DDD中 四層架構(gòu)：表現(xiàn)層，應(yīng)用層、領(lǐng)域?qū)雍突A(chǔ)層

四層中的應(yīng)用層是對(duì)三層架構(gòu)中領(lǐng)域?qū)舆M(jìn)行進(jìn)一步拆分。但是無論怎么分層，業(yè)務(wù)邏輯永遠(yuǎn)在領(lǐng)域?qū)印?/p>

三層架構(gòu)：

- 表現(xiàn)層： 負(fù)責(zé)向用戶展示信息和接收用戶的指令。需要負(fù)責(zé)處理展示邏輯，比如用戶通過我們的系統(tǒng)進(jìn)行信用卡還款，系統(tǒng)會(huì)返回三個(gè)狀態(tài)未申請(qǐng)，處理中，處理完成。表面層需要根據(jù)這個(gè)狀態(tài)給用戶返回不同的頁面，根據(jù)這三個(gè)不同的狀態(tài)，向用戶展示不同的中文說明。

- 領(lǐng)域?qū)樱?負(fù)責(zé)表達(dá)業(yè)務(wù)邏輯，是整個(gè)系統(tǒng)的核心層。比如信用卡還款服務(wù)。

- 持久層： 提供數(shù)據(jù)查詢和存儲(chǔ)服務(wù)，包括按照狀態(tài)查詢信用卡。

四層架構(gòu)：

• 表現(xiàn)層： 同三層架構(gòu)表現(xiàn)層。
• 應(yīng)用層： 定義軟件要完成的任務(wù)，不包含業(yè)務(wù)邏輯，而是協(xié)調(diào)，比如受理用戶請(qǐng)求的任務(wù)。負(fù)責(zé)非 業(yè)務(wù)邏輯(批量刪除、修改等)
• 領(lǐng)域?qū)樱?同三層架構(gòu)領(lǐng)域?qū)印?/li>
• 基礎(chǔ)層：為各層提供通用的技術(shù)能力。為領(lǐng)域?qū)犹峁?shù)據(jù)和文件存儲(chǔ)。

分層架構(gòu)最重要的是每一層關(guān)注自己的職責(zé)，持久層只負(fù)責(zé)提供查詢、更新和存儲(chǔ)數(shù)據(jù)的服務(wù)，和業(yè)務(wù)邏輯無關(guān)的，所以持久層提供按照還款狀態(tài)查詢信用卡的服務(wù)，這樣做的好處增加復(fù)用性，后續(xù)領(lǐng)域?qū)犹峁┱故疽堰€款的信用卡服務(wù)時(shí)能復(fù)用持久層的查詢服務(wù)。

分層架構(gòu)的好處

分層架構(gòu)的目的是通過關(guān)注點(diǎn)分離來降低系統(tǒng)的復(fù)雜度，同時(shí)滿足單一職責(zé)、高內(nèi)聚、低耦合、提高可復(fù)用性和降低維護(hù)成本。單一職責(zé)：每一層只負(fù)責(zé)一個(gè)職責(zé)，職責(zé)邊界清晰，如持久層只負(fù)責(zé)數(shù)據(jù)查詢和存儲(chǔ)，領(lǐng)域?qū)又回?fù) 責(zé)處理業(yè)務(wù)邏輯。

高內(nèi)聚： 分層是把相同的職責(zé)放在同一個(gè)層中，所有業(yè)務(wù)邏輯內(nèi)聚在領(lǐng)域?qū)印＿@樣做有什么好處呢?試想一下假如業(yè)務(wù)邏輯分散在每一層，修改功能需要去各層修改，測(cè)試業(yè)務(wù)邏輯需要測(cè)試所有層的代碼，這樣增加了整個(gè)軟件的復(fù)雜度和測(cè)試難度。

低耦合： 依賴關(guān)系非常簡(jiǎn)單，上層只能依賴于下層，沒有循環(huán)依賴。

可復(fù)用： 某項(xiàng)能力可以復(fù)用給多個(gè)業(yè)務(wù)流程。比如持久層提供按照還款狀態(tài)查詢信用卡的服務(wù)，既可以給申請(qǐng)信用卡做判斷使用，也可以給展示未還款信用卡使用。

易維護(hù)： 面對(duì)變更容易修改。把所有對(duì)外接口都放在對(duì)外接口層，一旦外部依賴的接口被修改，只需要改這個(gè)層的代碼即可。

以上這些既是分層的好處也是分層的原則，大家在分層時(shí)需要遵循以上原則，不恰當(dāng)?shù)姆謱訒?huì)違背了分層架構(gòu)的初衷。

分層架構(gòu)的缺點(diǎn)

分層架構(gòu)也有幾個(gè)缺點(diǎn)

開發(fā)成本高： 因?yàn)槎鄬臃謩e承擔(dān)各自的職責(zé)，增加功能需要在多個(gè)層增加代碼，這樣難免會(huì)增加開發(fā)成本。但是合理的能力抽象可以提高了復(fù)用性，又能降低開發(fā)成本。

性能略低： 業(yè)務(wù)流需要經(jīng)過多層代碼的處理，性能會(huì)有所消耗。

可擴(kuò)展性低： 因?yàn)樯舷聦又g存在耦合度，所有有些功能變化可能涉及到多層的修改。

六、領(lǐng)域模型(domain model)

領(lǐng)域模型是對(duì)領(lǐng)域內(nèi)的概念類或現(xiàn)實(shí)世界中對(duì)象的可視化表示。又稱概念模型、業(yè)務(wù)對(duì)象模型、領(lǐng)域?qū)ο竽Ｐ?、分析?duì)象模型。

它專注于分析問題領(lǐng)域本身，發(fā)掘重要的業(yè)務(wù)領(lǐng)域概念，并建立業(yè)務(wù)領(lǐng)域概念之間的關(guān)系。

優(yōu)點(diǎn)是系統(tǒng)層次結(jié)構(gòu)清楚，各層之間單向依賴，

Client -> (Business Facade) -> Business Logic -> Data Access Object  

可見，領(lǐng)域?qū)ο髱缀踔蛔鰝鬏斀橘|(zhì)的用處，不會(huì)影響到層次的劃分。

領(lǐng)域?qū)ο笾皇亲鳛楸４鏍顟B(tài)或者傳遞狀態(tài)使用，它是沒有生命的，只是數(shù)據(jù)沒有行為的對(duì)象不是真正的對(duì)象。

七、貧血模型

貧血模型是指領(lǐng)域?qū)ο罄镏挥?get 和 set 方法(一般是指POJO),所有的業(yè)務(wù)邏輯是不包含在這里面的而是放在 Business Logic層。

在使用Spring的時(shí)候，通常就暗示著我們使用的是貧血模型，我們把Domain類用來單純地儲(chǔ)存數(shù)據(jù)，Spring管不著這些類的注入和管理，Spring關(guān)心的邏輯層(比如單例的被池化了的Business Logic層) 可以被設(shè)計(jì)成Singleton的Bean。

假設(shè)我們這里改變一下，就在Domain類中提供業(yè)務(wù)邏輯方法，那么我們?cè)谑褂肧pring構(gòu)造這樣的數(shù)據(jù)Bean的時(shí)候會(huì)遇到很多麻煩，比如 Bean之間的引用，可能引起大范圍的Bean之間的潛逃構(gòu)造器的調(diào)用。

八、充血模型

大多業(yè)務(wù)邏輯和持久化放在Domain Object 里面，Business Logic只是簡(jiǎn)單封裝部分業(yè)務(wù)邏輯以及控制事務(wù)、權(quán)限等，這樣層次結(jié)構(gòu)就變成

Client -> (Business Facade) -> Business Logic -> Domain Object -> Data Access Object。 

優(yōu)點(diǎn)：

是面向?qū)ο?，Business Logic 符合單一職責(zé)，不像在貧血模型里面那樣包含所有的業(yè)務(wù)邏輯太過沉重。

缺點(diǎn)

如何劃分業(yè)務(wù)邏輯，什么樣的邏輯應(yīng)該放在 Domain Object中，什么樣的業(yè)務(wù)邏輯應(yīng)該放在Business Logic中，其實(shí)是比較模糊的。

即使劃分好了業(yè)務(wù)邏輯，由于分散在Business Logic和Domain Object層中，不能更好的劃分模塊開發(fā)。

熟悉業(yè)務(wù)邏輯的開發(fā)人員需要滲透到Domain Logic中去，而在Domain Logic又包含了持久化，對(duì)于開發(fā)者者這是十分混亂的。

如果Business Logic要控制事務(wù)并且為上層提供一個(gè)統(tǒng)一的服務(wù)調(diào)用入口點(diǎn)，它就必須把在Domain logic里實(shí)現(xiàn)的業(yè)務(wù)邏輯全部重新包裝一遍，完全屬于重復(fù)勞動(dòng)。

使用RoR開發(fā)時(shí)，每一個(gè)領(lǐng)域模型對(duì)象都可以具備自己的基礎(chǔ)業(yè)務(wù)方法，通常滿足充血模型的開發(fā)，充血模型更適合復(fù)雜業(yè)務(wù)邏輯的設(shè)計(jì)開發(fā)。

充血模型的層次和模塊的劃分是一門學(xué)問，對(duì)開發(fā)人員要求也比較高，可以考慮定義這樣的一些規(guī)則：

(1) 事務(wù)控制不要放在領(lǐng)取模型的對(duì)象中實(shí)現(xiàn)，可以放在facade中完成。

(2) 領(lǐng)域模型對(duì)象中只保留該模型驅(qū)動(dòng)的一般方法，對(duì)于業(yè)務(wù)特征明顯的特異場(chǎng)景方法調(diào)用放在facade中完成。

九、傳統(tǒng)的數(shù)據(jù)驅(qū)動(dòng)開發(fā)模式

View、Service、Dao 這種三層模式，開發(fā)者會(huì)很自然的寫出過程式代碼，這種開發(fā)方式中的對(duì)象只是數(shù)據(jù)載體，而沒有行為，是一種貧血對(duì)象模型，以數(shù)據(jù)為中心，以數(shù)據(jù)庫(kù)ER圖為設(shè)計(jì)驅(qū)動(dòng)，分層架構(gòu)在這種開發(fā)模式下可以認(rèn)為是數(shù)據(jù)處理和實(shí)現(xiàn)的過程。

十、限界上下文(Bounded Context)

限界上下文：定義了每個(gè)模型的應(yīng)用范圍

一個(gè)業(yè)務(wù)領(lǐng)域可以劃分成多個(gè)BC，它們之間通過Context Map進(jìn)行集成。BC是一個(gè)顯式的邊界，領(lǐng)域模型Bianc便存在于這個(gè)邊界之內(nèi)。領(lǐng)域模型是關(guān)于某個(gè)特定業(yè)務(wù)員領(lǐng)域的軟件模型，通常，領(lǐng)域模型通過對(duì)象模型來實(shí)現(xiàn)，這些對(duì)象同時(shí)包含了數(shù)據(jù)和行為，并且表達(dá)了準(zhǔn)確的業(yè)務(wù)含義。

關(guān)于限界上下文，有一個(gè)很形象的類別，細(xì)胞和細(xì)胞膜的類比：

細(xì)胞之所以能存在，是因?yàn)榧?xì)胞膜定義了什么在細(xì)胞內(nèi)，什么在細(xì)胞外，而且確認(rèn)了什么物質(zhì)可以通過細(xì)胞膜

BC可以類比為細(xì)胞膜，大型系統(tǒng)由于其復(fù)雜性，對(duì)于一個(gè)對(duì)象如果采取統(tǒng)一建模方式，可能會(huì)產(chǎn)生不可預(yù)測(cè)的效果。例如書中提到的客戶發(fā)票中的收費(fèi)對(duì)象故障，其實(shí)類似問題也在很多地方可以看到。

十一、什么是 CQRS?

CQRS —— Command Query Responsibility Segreation(命令查詢職責(zé)分離)，故名思義是將 command 與 query 分離的一種模式。這種命令與查詢的分離方式，可以更好地控制請(qǐng)求者的操作。查詢操作不會(huì)造成數(shù)據(jù)的修改，因而它屬于一種冪等操作，可以反復(fù)地發(fā)起，而不用擔(dān)心會(huì)對(duì)系統(tǒng)造成影響?；谶@種特性，我們還可以為其提供緩存，從而改進(jìn)查詢的性能。

query很好理解，就是我們經(jīng)常使用到的查詢。

那么 command 又是什么呢，我們可以看 CRUD，其實(shí)可以分為讀(R)和寫(CUD)，大部分情況就是一個(gè)方法要么是執(zhí)行一個(gè)Command完成一個(gè)動(dòng)作，要么就是查詢返回?cái)?shù)據(jù)，比如我們回答問題的人不應(yīng)該去修改問題。

只要充分理解了運(yùn)用CQRS模式的意圖，理解CQRS模式就變得容易了許多。下圖是CQRS框架AxonFramework官方文檔給出的CQRS架構(gòu)圖。

十二、統(tǒng)一語言(Ubiquitous Language)

業(yè)務(wù)人員和我們使用一樣的語言，我們的程序比如讓業(yè)務(wù)盡量集中在領(lǐng)域里，比如在傳統(tǒng)的數(shù)據(jù)驅(qū)動(dòng)里，如果說 張三喜歡李四，我們一般會(huì)這么寫

UserService.Love(zhangsan, lisi) 

但是我們業(yè)務(wù)人員很奇怪誰Love誰?為什么要UserService?, 如果我們寫成下面這樣

zhangsan.Love(lisi) 

如果我們用

Company.hire(employee) 來替代 companyservice.hire(company,employee) 

這樣我們就更容易讓業(yè)務(wù)人員參與進(jìn)來，而且代碼可以更易于表示真實(shí)的業(yè)務(wù)場(chǎng)景。

以上是根據(jù)課堂筆記來記錄的，如果有錯(cuò)誤或者不懂的地方，歡迎大家在下面留言。