DDD

DDD，全稱是：“Domain-Driven-Design”，翻譯過來就是：領域驅動設計(DDD）。

DDD，最早是埃里克·埃文斯（Eric Evans），出版了《領域驅動設計》這本書，標志著領域驅動設計（DDD）的正式誕生。

DDD 強調以業(yè)務需求為中心，以領域模型為核心，通過不斷迭代開發(fā)，確保軟件系統(tǒng)能夠準確反映業(yè)務邏輯、和需求。

DDD原理

在領域驅動設計（DDD）中，領域模型通常被分為四層，以幫助開發(fā)人員將業(yè)務邏輯、與技術實現(xiàn)，進行有效的分離。

如下圖所示：

圖片

DDD 的四層架構，提供了一個清晰的分層結構，使得系統(tǒng)的各個部分職責分明。

1.用戶界面層

用戶界面層，負責與用戶交互，顯示數(shù)據(jù)并收集用戶輸入。

這一層主要處理 UI/UX 邏輯，如：數(shù)據(jù)展示、用戶輸入驗證.........等。

它是系統(tǒng)的入口，通過各種用戶界面，比如：如網頁、移動應用、桌面應用、與最終用戶進行交互。

2.應用層

應用層定義了系統(tǒng)的主要用例，通過服務接口暴露這些用例，以便用戶界面層調用。

該層負責管理事務、協(xié)調不同領域對象的交互，以及處理用戶請求的工作流。

應用層還負責管理事務、一致性，以及調度各種領域對象，以完成用戶的業(yè)務需求。

比如：電商系統(tǒng)中的訂單管理、庫存管理、客戶賬戶管理.....等核心業(yè)務邏輯。

3.領域層

領域層是 DDD 的核心部分，負責：實現(xiàn)業(yè)務邏輯和規(guī)則。

DDD ，包含了領域模型（比如：實體、值對象、聚合、領域服務...等），這些模型直接反映了業(yè)務需求。

領域層具有高度內聚性，所有業(yè)務邏輯都集中在這一層，避免邏輯分散。

4.基礎設施層

基礎設施層，負責技術實現(xiàn)的細節(jié)，比如：持久化、消息傳遞、外部系統(tǒng)集成、日志記錄等。

比如：MySQL 數(shù)據(jù)庫訪問層、Redis 緩存層、Kafka 消息隊列集成.......等等。

基礎設施層應盡量、與領域層、和應用層解耦，以保持系統(tǒng)的靈活性、和可替換性。

通過這種分層設計，開發(fā)團隊可以更好地管理系統(tǒng)的復雜性，確保業(yè)務邏輯的準確性和系統(tǒng)的可維護性。

DDD實踐

DDD 的實施，一般包含如下步驟：

圖片

1.領域

首先，通過與領域專家的緊密合作，深入理解業(yè)務領域，識別核心子領域、和業(yè)務邏輯。

領域是指一個特定的業(yè)務領域、或問題空間。

DDD 強調對領域的深入理解，以構建符合業(yè)務需求的軟件系統(tǒng)。

領域內的所有規(guī)則、術語和概念都是業(yè)務專家、和開發(fā)團隊共同理解、和認同的。

比如：電商系統(tǒng)的“領域”，可以是整個在線購物平臺，它包括了：商品管理、訂單處理、支付系統(tǒng)、客戶管理等多個子領域。

這個領域中的所有業(yè)務規(guī)則、和活動，都圍繞著：如何支持用戶購買商品、處理訂單、進行支付等關鍵業(yè)務功能。

2.領域模型

領域模型是對領域內概念的抽象和簡化，是 DDD 中的核心。

領域模型通過實體、值對象、聚合等構建塊來描述業(yè)務邏輯和規(guī)則。

3.限界上下文

限界上下文，是在一個大的領域內劃定的一個明確邊界，用于劃分、和隔離不同子域或模型的區(qū)域。

在不同的限界上下文內，相同的術語可能具有不同的含義。

一個限界上下文包含一個清晰定義的領域模型，確保在該上下文中，概念的一致性、和統(tǒng)一性。

如下圖所示：

圖片

比如：在電商系統(tǒng)中，不同的限界上下文，可能包括：“訂單管理上下文”、和“庫存管理上下文”。

訂單管理上下文：處理用戶訂單的創(chuàng)建、修改、支付、取消....等功能。

在這個上下文中，“訂單”主要涉及客戶信息、支付狀態(tài)。。。等。

庫存管理上下文：負責管理商品的庫存數(shù)量、倉庫位置。。。等。

在這個上下文中，“訂單”更多地與庫存扣減、出貨等操作相關。

4.模型驅動設計

模型驅動設計是DDD的核心理念，它主張以領域模型為基礎，來驅動軟件系統(tǒng)的設計與開發(fā)。

比如：在訂單管理上下文中，團隊通過與領域專家討論，創(chuàng)建了一個領域模型。

其中包括“訂單（Order）”、“訂單項（OrderItem）”...等實體，以及訂單的各種狀態(tài)（如“待支付”、“已支付”、“已發(fā)貨”等）。

該模型驅動了系統(tǒng)的設計，開發(fā)團隊根據(jù)模型定義數(shù)據(jù)庫結構、API接口和業(yè)務邏輯，實現(xiàn)了與訂單相關的功能。

5.聚合

聚合是指一組相關對象的集合，通常通過聚合根進行訪問、和管理。

聚合根是控制、和管理聚合內部狀態(tài)的一部分，它負責維護聚合的一致性。

比如：在訂單管理上下文中，“訂單”可以作為一個聚合，包含：“訂單項（OrderItem）”、和“支付信息（PaymentInfo）”。

在這個聚合中，所有操作都通過訂單這個聚合根來進行，以確保聚合內部的規(guī)則和約束得以維護。

6.實體

實體是具有唯一標識的對象，其生命周期貫穿系統(tǒng)中的多個狀態(tài)轉變。

實體的標識符通常是不可變的，而它的狀態(tài)可以變化。

在校園教務系統(tǒng)中，“學生（Student）”就是一個實體。

如下圖所示：

圖片

每個學生都有一個唯一的學號作為標識符，即使學生的姓名、地址等其他屬性發(fā)生變化，學號仍然保持不變，學號是這個實體的唯一標識。

7.值對象

在“學生信息管理上下文”中，“聯(lián)系方式（ContactInfo）”可以作為一個值對象。

聯(lián)系方式（ContactInfo）：包含電話、郵箱...等信息。

DDD領域驅動設計，可以幫助團隊更好地組織、和管理復雜的業(yè)務邏輯，使系統(tǒng)能夠有效應對業(yè)務需求的變化。