DDD最全詳解(圖文全面總結)
DDD
DDD,全稱是:“Domain-Driven-Design”,翻譯過來就是:領域驅(qū)動設計(DDD)。
DDD,最早是埃里克·埃文斯(Eric Evans),出版了《領域驅(qū)動設計》這本書,標志著領域驅(qū)動設計(DDD)的正式誕生。
DDD 強調(diào)以業(yè)務需求為中心,以領域模型為核心,通過不斷迭代開發(fā),確保軟件系統(tǒng)能夠準確反映業(yè)務邏輯、和需求。
DDD原理
在領域驅(qū)動設計(DDD)中,領域模型通常被分為四層,以幫助開發(fā)人員將業(yè)務邏輯、與技術實現(xiàn),進行有效的分離。
如下圖所示:
圖片
DDD 的四層架構,提供了一個清晰的分層結構,使得系統(tǒng)的各個部分職責分明。
1.用戶界面層
用戶界面層,負責與用戶交互,顯示數(shù)據(jù)并收集用戶輸入。
這一層主要處理 UI/UX 邏輯,如:數(shù)據(jù)展示、用戶輸入驗證.........等。
它是系統(tǒng)的入口,通過各種用戶界面,比如:如網(wǎng)頁、移動應用、桌面應用、與最終用戶進行交互。
2.應用層
應用層定義了系統(tǒng)的主要用例,通過服務接口暴露這些用例,以便用戶界面層調(diào)用。
該層負責管理事務、協(xié)調(diào)不同領域?qū)ο蟮慕换ィ约疤幚碛脩粽埱蟮墓ぷ髁鳌?/p>
應用層還負責管理事務、一致性,以及調(diào)度各種領域?qū)ο螅酝瓿捎脩舻臉I(yè)務需求。
比如:電商系統(tǒng)中的訂單管理、庫存管理、客戶賬戶管理.....等核心業(yè)務邏輯。
3.領域?qū)?/h3>
領域?qū)邮?DDD 的核心部分,負責:實現(xiàn)業(yè)務邏輯和規(guī)則。
DDD ,包含了領域模型(比如:實體、值對象、聚合、領域服務...等),這些模型直接反映了業(yè)務需求。
領域?qū)泳哂懈叨葍?nèi)聚性,所有業(yè)務邏輯都集中在這一層,避免邏輯分散。
4.基礎設施層
基礎設施層,負責技術實現(xiàn)的細節(jié),比如:持久化、消息傳遞、外部系統(tǒng)集成、日志記錄等。
比如:MySQL 數(shù)據(jù)庫訪問層、Redis 緩存層、Kafka 消息隊列集成.......等等。
基礎設施層應盡量、與領域?qū)印⒑蛻脤咏怦睿员3窒到y(tǒng)的靈活性、和可替換性。
通過這種分層設計,開發(fā)團隊可以更好地管理系統(tǒng)的復雜性,確保業(yè)務邏輯的準確性和系統(tǒng)的可維護性。
DDD實踐
DDD 的實施,一般包含如下步驟:
圖片
1.領域
首先,通過與領域?qū)<业木o密合作,深入理解業(yè)務領域,識別核心子領域、和業(yè)務邏輯。
領域是指一個特定的業(yè)務領域、或問題空間。
DDD 強調(diào)對領域的深入理解,以構建符合業(yè)務需求的軟件系統(tǒng)。
領域內(nèi)的所有規(guī)則、術語和概念都是業(yè)務專家、和開發(fā)團隊共同理解、和認同的。
比如:電商系統(tǒng)的“領域”,可以是整個在線購物平臺,它包括了:商品管理、訂單處理、支付系統(tǒng)、客戶管理等多個子領域。
這個領域中的所有業(yè)務規(guī)則、和活動,都圍繞著:如何支持用戶購買商品、處理訂單、進行支付等關鍵業(yè)務功能。
2.領域模型
領域模型是對領域內(nèi)概念的抽象和簡化,是 DDD 中的核心。
領域模型通過實體、值對象、聚合等構建塊來描述業(yè)務邏輯和規(guī)則。
3.限界上下文
限界上下文,是在一個大的領域內(nèi)劃定的一個明確邊界,用于劃分、和隔離不同子域或模型的區(qū)域。
在不同的限界上下文內(nèi),相同的術語可能具有不同的含義。
一個限界上下文包含一個清晰定義的領域模型,確保在該上下文中,概念的一致性、和統(tǒng)一性。
如下圖所示:
圖片
比如:在電商系統(tǒng)中,不同的限界上下文,可能包括:“訂單管理上下文”、和“庫存管理上下文”。
訂單管理上下文:處理用戶訂單的創(chuàng)建、修改、支付、取消....等功能。
在這個上下文中,“訂單”主要涉及客戶信息、支付狀態(tài)。。。等。
庫存管理上下文:負責管理商品的庫存數(shù)量、倉庫位置。。。等。
在這個上下文中,“訂單”更多地與庫存扣減、出貨等操作相關。
4.模型驅(qū)動設計
模型驅(qū)動設計是DDD的核心理念,它主張以領域模型為基礎,來驅(qū)動軟件系統(tǒng)的設計與開發(fā)。
比如:在訂單管理上下文中,團隊通過與領域?qū)<矣懻摚瑒?chuàng)建了一個領域模型。
其中包括“訂單(Order)”、“訂單項(OrderItem)”...等實體,以及訂單的各種狀態(tài)(如“待支付”、“已支付”、“已發(fā)貨”等)。
該模型驅(qū)動了系統(tǒng)的設計,開發(fā)團隊根據(jù)模型定義數(shù)據(jù)庫結構、API接口和業(yè)務邏輯,實現(xiàn)了與訂單相關的功能。
5.聚合
聚合是指一組相關對象的集合,通常通過聚合根進行訪問、和管理。
聚合根是控制、和管理聚合內(nèi)部狀態(tài)的一部分,它負責維護聚合的一致性。
比如:在訂單管理上下文中,“訂單”可以作為一個聚合,包含:“訂單項(OrderItem)”、和“支付信息(PaymentInfo)”。
在這個聚合中,所有操作都通過訂單這個聚合根來進行,以確保聚合內(nèi)部的規(guī)則和約束得以維護。
6.實體
實體是具有唯一標識的對象,其生命周期貫穿系統(tǒng)中的多個狀態(tài)轉變。
實體的標識符通常是不可變的,而它的狀態(tài)可以變化。
在校園教務系統(tǒng)中,“學生(Student)”就是一個實體。
如下圖所示:
圖片
每個學生都有一個唯一的學號作為標識符,即使學生的姓名、地址等其他屬性發(fā)生變化,學號仍然保持不變,學號是這個實體的唯一標識。
7.值對象
在“學生信息管理上下文”中,“聯(lián)系方式(ContactInfo)”可以作為一個值對象。
聯(lián)系方式(ContactInfo):包含電話、郵箱...等信息。
DDD領域驅(qū)動設計,可以幫助團隊更好地組織、和管理復雜的業(yè)務邏輯,使系統(tǒng)能夠有效應對業(yè)務需求的變化。