DDD

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

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

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

DDD原理

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

如下圖所示：

圖片

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

1.用戶界面層

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

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

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

2.應用層

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

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

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

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

3.領域層

領域層是 DDD 的核心部分，負責：實現業務邏輯和規則。

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

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

4.基礎設施層

基礎設施層，負責技術實現的細節，比如：持久化、消息傳遞、外部系統集成、日志記錄等。

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

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

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

DDD實踐

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

圖片

1.領域

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

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

DDD 強調對領域的深入理解，以構建符合業務需求的軟件系統。

領域內的所有規則、術語和概念都是業務專家、和開發團隊共同理解、和認同的。

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

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

2.領域模型

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

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

3.限界上下文

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

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

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

如下圖所示：

圖片

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

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

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

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

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

4.模型驅動設計

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

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

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

該模型驅動了系統的設計，開發團隊根據模型定義數據庫結構、API接口和業務邏輯，實現了與訂單相關的功能。

5.聚合

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

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

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

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

6.實體

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

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

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

如下圖所示：

圖片

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

7.值對象

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

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

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