建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號「牧小農(nóng)」，作者牧小農(nóng)。轉(zhuǎn)載本文請聯(lián)系牧小農(nóng)公眾號。
一、前言
最近公司一場有關于領域驅(qū)動設計的技術分享會，主要講解了服務的劃分，Restful API的設計，如何將抽象具有統(tǒng)一業(yè)務的范疇的Model，使其模塊化，同時能夠提煉組合多個模塊，使得業(yè)務能夠獨立服務化，在軟件開發(fā)中如何降低系統(tǒng)的復雜度是一個永恒的挑戰(zhàn)，在之前都是通過一系列的設計模式或者范例來降低一些比較常見的復雜度，這些都是通過技術手段來解決技術問題，沒有從根本上解決業(yè)務上的問題，但是在03年 Eric Evans 的《Domain Driven Design》 中，才是真正的從業(yè)務的角度出發(fā)，并且提供了一整套的針對純業(yè)務開發(fā)的架構(gòu)思路。為了更加深入理解，看了不少資料后，對DDD有了一點小小的個人心得，所以整理了一下，分享出來，希望能夠?qū)Υ蠹矣袔椭?/p>
二、什么是DDD
DDD 是 Eric Evans 在2003年出版的書名，同時也是這個架構(gòu)設計方法名的起源。Eric Evans “領域驅(qū)動設計之父”，世界杰出軟件建模專家。他創(chuàng)建的 “Domain Language” 公司，就是致力幫助公司機構(gòu)創(chuàng)建與業(yè)務緊密相關的軟件。
DDD 不是一套架構(gòu)，而是一種架構(gòu)思想，所以導致在代碼層面缺乏了足夠的約束，因此 DDD 在實際應用中上手門檻比較高，而且在絕大部分公司中實際應用中是沒有應用到的，或者說只是應用到了 DDD 部分思想 比如：建模的思想，對整個架構(gòu)體系的思想是無法落地的，而且一些依然火熱的ORM工具(Hibernate)助長了貧血模型的擴散，同樣因為傳統(tǒng)的基于數(shù)據(jù)庫技術以及MVC的四成架構(gòu)應用(UI、Business、Data Access、Database)依然能夠為我們解決絕大部分的應用開發(fā)。
之前的服務架構(gòu) 局限于單機 +LB 用MVC提供的Rest接口提供外部服務調(diào)用，或者用WebService 做RPC調(diào)用，到了2014年，SOA開始火熱起來了，微服務開始如雨后春筍一樣的開始冒頭，怎么把一個應用或者項目合理化的進行拆分多個微服務，成為了各個技術負責人的思考的重點，而在DDD里面的 Bounded Context(限界上下文)中就為我們提供了一整套合理的架構(gòu)思想。
但是 DDD 可以讓我們思考 在我們的項目中哪些是可以被服務化拆分，哪些業(yè)務邏輯需要被聚合在一起，實現(xiàn)最小的開發(fā)和維護成本。
三、領域驅(qū)動設計-基本概念
DDD 的全稱為 Domain Driven Design，即領域驅(qū)動設計，DDD不是架構(gòu)，而是一種方法論(Methodology)，微服務架構(gòu)從一出來就沒有很好的理論支撐如何合理的劃分服務邊界。
在我們早期常見的軟件開發(fā)就是拿到產(chǎn)品需求后，先考慮數(shù)據(jù)庫設計，根據(jù)數(shù)據(jù)庫設計，建立對應的實體層、服務層等等，但是這種方式會將 分析、設計和業(yè)務需求脫節(jié)，而更多的是直接考慮應該如何實現(xiàn)，這就有點本末倒置了，而DDD 是從問題本身出發(fā)進行的設計方法。
概念： 系統(tǒng)設計應該是一種以領域為核心的設計和開發(fā)，設計應該通過維護一個深度反應領域概念的模型，以及提供可行的經(jīng)過實踐校驗的大量模式來應對領域的復雜性。
DDD 更像小顆粒的迭代設計，最小單元是 領域模型(DomainModel)
什么是領域(Domain)?
什么是領域?比如我們經(jīng)常使用的某寶、某東、屬于網(wǎng)上電商領域，那么這些領域就會有對應的商品瀏覽、購物車、下單、扣減庫存、供應商、付款等等核心環(huán)境。再比如我們想做一個聊天系統(tǒng)，那這個系統(tǒng)的核心業(yè)務就要確定，比如有 聯(lián)系人、分組、朋友圈、視頻、聊天記錄等功能。
所以，我們可以得知，一個領域的本質(zhì)上可以理解為一個問題域，只要是同一個領域的，那么他們 一定會有相同的問題域，因此只要我們確定了系統(tǒng)所屬的領域，那這個系統(tǒng)的核心業(yè)務，也就是我們要解決的關鍵問題，問題的范圍邊界也就基本確定了。
什么是設計(Design)?
DDD 中的設計主要是指領域模型的設計，為什么說是領域模型的設計而不是架構(gòu)設計或者其他的設計?因為DDD是一種基于模型驅(qū)動開發(fā)的軟件開發(fā)思想，強調(diào)領域模型是這個系統(tǒng)的核心，領域模型也是整個系統(tǒng)的核心價值所在，每一個領域，都有對應的領域模型，因為領域模型能夠很好的幫助我們解決復雜的業(yè)務問題。領域模型綁定了領域和代碼的是吸納，確保了最終的代碼實現(xiàn)就一定是解決了領域中的核心問題，
四、四色原型建模
簡單描述：
某個人(Party)的角色(PartyRole)在某個地點(Place)的角色(PlaceRole)用某個東西(Thing)的角色(ThingRole)做了某件事情(MomentInterval)
PartPlaceThing：簡稱PPT，用淡綠色表示，常見的PPT有：部門、崗位、人員、地點、物品等。
Description：簡稱Des，用淡藍色表示，主要用來對PPT進行描述，常見的Des有：部門類型、崗位層級、人員類型、地點區(qū)域、物品分類等。
Role：用淡黃色表示，主要表示PPT在某個場景下扮演的角色，常見的角色有：財務類部門、管理類崗位、請假者、銷售點、產(chǎn)品等。
MomentInterval：簡稱MI，用淡紅色表示，主要表示在一刻或一段時間內(nèi)發(fā)生的一件事情，常見的MI有：部門移動、崗位移動、員工離職、產(chǎn)品銷售等。
MomentInteval：簡稱MIDetail，用淡紅色表示，主要表示MI的明細。
五、分層架構(gòu)
分層架構(gòu)是將軟件模塊按照水平切分的方式分成多個層
最基本的是分層架構(gòu)是三層：即表現(xiàn)層，領域?qū)雍蛿?shù)據(jù)持久層
DDD中 四層架構(gòu)：表現(xiàn)層，應用層、領域?qū)雍突A層
四層中的應用層是對三層架構(gòu)中領域?qū)舆M行進一步拆分。但是無論怎么分層，業(yè)務邏輯永遠在領域?qū)印?/p>
三層架構(gòu)：
- 表現(xiàn)層： 負責向用戶展示信息和接收用戶的指令。需要負責處理展示邏輯，比如用戶通過我們的系統(tǒng)進行信用卡還款，系統(tǒng)會返回三個狀態(tài)未申請，處理中，處理完成。表面層需要根據(jù)這個狀態(tài)給用戶返回不同的頁面，根據(jù)這三個不同的狀態(tài)，向用戶展示不同的中文說明。
- 領域?qū)樱?負責表達業(yè)務邏輯，是整個系統(tǒng)的核心層。比如信用卡還款服務。
- 持久層： 提供數(shù)據(jù)查詢和存儲服務，包括按照狀態(tài)查詢信用卡。
四層架構(gòu)：
- 表現(xiàn)層： 同三層架構(gòu)表現(xiàn)層。
- 應用層： 定義軟件要完成的任務，不包含業(yè)務邏輯，而是協(xié)調(diào)，比如受理用戶請求的任務。負責非 業(yè)務邏輯(批量刪除、修改等)
- 領域?qū)樱?同三層架構(gòu)領域?qū)印?/li>
- 基礎層：為各層提供通用的技術能力。為領域?qū)犹峁?shù)據(jù)和文件存儲。
分層架構(gòu)最重要的是每一層關注自己的職責，持久層只負責提供查詢、更新和存儲數(shù)據(jù)的服務，和業(yè)務邏輯無關的，所以持久層提供按照還款狀態(tài)查詢信用卡的服務，這樣做的好處增加復用性，后續(xù)領域?qū)犹峁┱故疽堰€款的信用卡服務時能復用持久層的查詢服務。
分層架構(gòu)的好處
分層架構(gòu)的目的是通過關注點分離來降低系統(tǒng)的復雜度，同時滿足單一職責、高內(nèi)聚、低耦合、提高可復用性和降低維護成本。單一職責：每一層只負責一個職責，職責邊界清晰，如持久層只負責數(shù)據(jù)查詢和存儲，領域?qū)又回?責處理業(yè)務邏輯。
高內(nèi)聚： 分層是把相同的職責放在同一個層中，所有業(yè)務邏輯內(nèi)聚在領域?qū)?。這樣做有什么好處呢?試想一下假如業(yè)務邏輯分散在每一層，修改功能需要去各層修改，測試業(yè)務邏輯需要測試所有層的代碼，這樣增加了整個軟件的復雜度和測試難度。
低耦合： 依賴關系非常簡單，上層只能依賴于下層，沒有循環(huán)依賴。
可復用： 某項能力可以復用給多個業(yè)務流程。比如持久層提供按照還款狀態(tài)查詢信用卡的服務，既可以給申請信用卡做判斷使用，也可以給展示未還款信用卡使用。
易維護： 面對變更容易修改。把所有對外接口都放在對外接口層，一旦外部依賴的接口被修改，只需要改這個層的代碼即可。
以上這些既是分層的好處也是分層的原則，大家在分層時需要遵循以上原則，不恰當?shù)姆謱訒`背了分層架構(gòu)的初衷。
分層架構(gòu)的缺點
分層架構(gòu)也有幾個缺點
開發(fā)成本高： 因為多層分別承擔各自的職責，增加功能需要在多個層增加代碼，這樣難免會增加開發(fā)成本。但是合理的能力抽象可以提高了復用性，又能降低開發(fā)成本。
性能略低： 業(yè)務流需要經(jīng)過多層代碼的處理，性能會有所消耗。
可擴展性低： 因為上下層之間存在耦合度，所有有些功能變化可能涉及到多層的修改。
六、領域模型(domain model)
領域模型是對領域內(nèi)的概念類或現(xiàn)實世界中對象的可視化表示。又稱概念模型、業(yè)務對象模型、領域?qū)ο竽Ｐ汀⒎治鰧ο竽Ｐ汀?/p>
它專注于分析問題領域本身，發(fā)掘重要的業(yè)務領域概念，并建立業(yè)務領域概念之間的關系。
優(yōu)點是系統(tǒng)層次結(jié)構(gòu)清楚，各層之間單向依賴，
- Client -> (Business Facade) -> Business Logic -> Data Access Object
可見，領域?qū)ο髱缀踔蛔鰝鬏斀橘|(zhì)的用處，不會影響到層次的劃分。
領域?qū)ο笾皇亲鳛楸４鏍顟B(tài)或者傳遞狀態(tài)使用，它是沒有生命的，只是數(shù)據(jù)沒有行為的對象不是真正的對象。
七、貧血模型
貧血模型是指領域?qū)ο罄镏挥?get 和 set 方法(一般是指POJO),所有的業(yè)務邏輯是不包含在這里面的而是放在 Business Logic層。
在使用Spring的時候，通常就暗示著我們使用的是貧血模型，我們把Domain類用來單純地儲存數(shù)據(jù)，Spring管不著這些類的注入和管理，Spring關心的邏輯層(比如單例的被池化了的Business Logic層) 可以被設計成Singleton的Bean。
假設我們這里改變一下，就在Domain類中提供業(yè)務邏輯方法，那么我們在使用Spring構(gòu)造這樣的數(shù)據(jù)Bean的時候會遇到很多麻煩，比如 Bean之間的引用，可能引起大范圍的Bean之間的潛逃構(gòu)造器的調(diào)用。
八、充血模型
大多業(yè)務邏輯和持久化放在Domain Object 里面，Business Logic只是簡單封裝部分業(yè)務邏輯以及控制事務、權限等，這樣層次結(jié)構(gòu)就變成
- Client -> (Business Facade) -> Business Logic -> Domain Object -> Data Access Object。
優(yōu)點：
是面向?qū)ο?，Business Logic 符合單一職責，不像在貧血模型里面那樣包含所有的業(yè)務邏輯太過沉重。
缺點
如何劃分業(yè)務邏輯，什么樣的邏輯應該放在 Domain Object中，什么樣的業(yè)務邏輯應該放在Business Logic中，其實是比較模糊的。
即使劃分好了業(yè)務邏輯，由于分散在Business Logic和Domain Object層中，不能更好的劃分模塊開發(fā)。
熟悉業(yè)務邏輯的開發(fā)人員需要滲透到Domain Logic中去，而在Domain Logic又包含了持久化，對于開發(fā)者者這是十分混亂的。
如果Business Logic要控制事務并且為上層提供一個統(tǒng)一的服務調(diào)用入口點，它就必須把在Domain logic里實現(xiàn)的業(yè)務邏輯全部重新包裝一遍，完全屬于重復勞動。
使用RoR開發(fā)時，每一個領域模型對象都可以具備自己的基礎業(yè)務方法，通常滿足充血模型的開發(fā)，充血模型更適合復雜業(yè)務邏輯的設計開發(fā)。
充血模型的層次和模塊的劃分是一門學問，對開發(fā)人員要求也比較高，可以考慮定義這樣的一些規(guī)則：
(1) 事務控制不要放在領取模型的對象中實現(xiàn)，可以放在facade中完成。
(2) 領域模型對象中只保留該模型驅(qū)動的一般方法，對于業(yè)務特征明顯的特異場景方法調(diào)用放在facade中完成。
九、傳統(tǒng)的數(shù)據(jù)驅(qū)動開發(fā)模式
View、Service、Dao 這種三層模式，開發(fā)者會很自然的寫出過程式代碼，這種開發(fā)方式中的對象只是數(shù)據(jù)載體，而沒有行為，是一種貧血對象模型，以數(shù)據(jù)為中心，以數(shù)據(jù)庫ER圖為設計驅(qū)動，分層架構(gòu)在這種開發(fā)模式下可以認為是數(shù)據(jù)處理和實現(xiàn)的過程。
十、限界上下文(Bounded Context)
限界上下文：定義了每個模型的應用范圍
一個業(yè)務領域可以劃分成多個BC，它們之間通過Context Map進行集成。BC是一個顯式的邊界，領域模型Bianc便存在于這個邊界之內(nèi)。領域模型是關于某個特定業(yè)務員領域的軟件模型，通常，領域模型通過對象模型來實現(xiàn)，這些對象同時包含了數(shù)據(jù)和行為，并且表達了準確的業(yè)務含義。
關于限界上下文，有一個很形象的類別，細胞和細胞膜的類比：
細胞之所以能存在，是因為細胞膜定義了什么在細胞內(nèi)，什么在細胞外，而且確認了什么物質(zhì)可以通過細胞膜
BC可以類比為細胞膜，大型系統(tǒng)由于其復雜性，對于一個對象如果采取統(tǒng)一建模方式，可能會產(chǎn)生不可預測的效果。例如書中提到的客戶發(fā)票中的收費對象故障，其實類似問題也在很多地方可以看到。
十一、什么是 CQRS?
CQRS —— Command Query Responsibility Segreation(命令查詢職責分離)，故名思義是將 command 與 query 分離的一種模式。這種命令與查詢的分離方式，可以更好地控制請求者的操作。查詢操作不會造成數(shù)據(jù)的修改，因而它屬于一種冪等操作，可以反復地發(fā)起，而不用擔心會對系統(tǒng)造成影響。基于這種特性，我們還可以為其提供緩存，從而改進查詢的性能。
query很好理解，就是我們經(jīng)常使用到的查詢。
那么 command 又是什么呢，我們可以看 CRUD，其實可以分為讀(R)和寫(CUD)，大部分情況就是一個方法要么是執(zhí)行一個Command完成一個動作，要么就是查詢返回數(shù)據(jù)，比如我們回答問題的人不應該去修改問題。
只要充分理解了運用CQRS模式的意圖，理解CQRS模式就變得容易了許多。下圖是CQRS框架AxonFramework官方文檔給出的CQRS架構(gòu)圖。
十二、統(tǒng)一語言(Ubiquitous Language)
業(yè)務人員和我們使用一樣的語言，我們的程序比如讓業(yè)務盡量集中在領域里，比如在傳統(tǒng)的數(shù)據(jù)驅(qū)動里，如果說 張三喜歡李四，我們一般會這么寫
- UserService.Love(zhangsan, lisi)
但是我們業(yè)務人員很奇怪誰Love誰?為什么要UserService?, 如果我們寫成下面這樣
- zhangsan.Love(lisi)
如果我們用
- Company.hire(employee) 來替代 companyservice.hire(company,employee)
這樣我們就更容易讓業(yè)務人員參與進來，而且代碼可以更易于表示真實的業(yè)務場景。
以上是根據(jù)課堂筆記來記錄的，如果有錯誤或者不懂的地方，歡迎大家在下面留言。
分享名稱：淺析DDD領域驅(qū)動設計
文章轉(zhuǎn)載：http://m.5511xx.com/article/djiisso.html
