DDD的奇幻世界：從小積木到藝術品的設計之旅
1. 背景
DDD 是一個門檻很高的設計方法，里面涉及眾多概念，各概念間相互關聯相互制約，大大增加了落地的難度。但，當真正落地之后，你會發現還是有很多技巧能大幅降低學習成本，實現快速上手。
學習 DDD 最關鍵的一點便是：使用面向對象思維去思考問題。
這個說起來很抽象，面向對象其實很簡單，就像孩子們玩的樂高積木：
- 【組件】每個小積木都有自己的形狀（對象自身功能），也都有自己的凸起或插槽（對象暴露的接口或能力）；
- 【關系】多個小積木可以組裝成一個大積木，多個大積木可以組裝成更大的積木（通過對象間的組合實現更強大的功能）；
- 【功能】多個大積木最終組成“藝術品”（通過對象間的協作實現某個功能）；
- 在 DDD 中也是一樣的：
- 【組件】聚合根是DDD中最核心的組件，對內維護高內聚的對象集合，對外提供原子業務能力；
- 【關系】應用服務、領域服務、領域事件 對多個組件進行編排，實現業務流程；
- 【功能】領域內部能力 通過 應用服務 暴露給外部調用者，從而滿足業務需求；
2. 原子能力
這里的原子能力主要指的是聚合根所提供的業務方法，從業務或技術視角都是不可拆分的最小操作單元。
2.1. 聚合根
在 DDD 中，聚合根是一個重要的概念，它是一組具有內在一致性的相關對象的根，用來限制對象的邊界，可以保證聚合內部的對象間關聯關系和業務規則得到統一的管理和維護。
聚合根是聚合的一個實體，作為整個聚合的唯一入口點，通過它才能訪問整個聚合。在DDD中，聚合被定義為一組相關對象的集合，這些對象在業務上有著緊密的聯系，需要被當作一個整體來對待。聚合根是這個整體的根節點，它負責維護整個聚合的完整性和一致性。
很抽象，讓我們看個示例：
電商訂單系統主要由以下幾個實體組成：
- 訂單（Order）。記錄用戶的一次生單，主要保存用戶、支付金額、訂單狀態等；
- 訂單項（OrderItem）。購買的單個商品，主要保存商品單價、售價、應付金額等；
- 支付記錄（Pay）。用戶的支付信息，包括支付渠道、支付金額、支付時間等；
- 收貨地址（Address）。用戶的收貨地址；
這幾個實體存在非常強的一致性保障，特別是在金額方面：
- 訂單的支付金額等于所有訂單項金額總和；
- 支付記錄的待支付金額必須與訂單支付金額一致；
如何保障訂單、訂單項、支付記錄上的金額是強一致的呢？小心編碼+謹慎測試？
那加入更多的應用場景又該怎么處理呢？比如 優惠券、優惠活動、手工改價、調整快遞費用等，這將變成一個燙手山芋。
解決方案便是將這幾個實體作為一個整體來思考，也就是聚合的概念。
聚合是DDD的一種設計模式，它的本質是建立比對象粒度更大的邊界，聚合了那些緊密聯系的對象，形成了一個業務上的整體。
圖片
如上圖所示：
- Order、OrderItem、Pay 和 Address 不在單獨處理，而是組成了一個更大的對象，也就是聚合；
- Order 是這個聚合的聚合根，對內協調各個對象，對外提供唯一的訪問入口；
- OrderItem、Pay、Address 作為非聚合根的內部實體，不可直接對外提供服務，僅接受 Order 的調用；
這樣的調整，能否保障 Order、OrderItem、Pay 三者間的強一致關系呢？讓我們從代碼層面進行細致分析：
生單：
// 靜態工廠，封裝復雜的 Order 創建邏輯，并保障創建的 Order 對象是有效的
public static Order create(CreateOrderCommand createOrderCommand) {
Order order = new Order(createOrderCommand.getUserId());
order.setAddress(Address.create(createOrderCommand));
order.setPay(new Pay());
order.addItems(createOrderCommand.getItems());
order.init();
return order;
}
// 添加 OrderItem，并計算總金額
private void addItems(List<OrderItemDTO> items) {
if (!CollectionUtils.isEmpty(items)){
items.forEach(item ->{
// orderItem.setPrice(orderItem.getPrice() * orderItem.getQuantity());
OrderItem orderItem = OrderItem.create(item);
this.orderItems.add(orderItem);
this.totalSellingPrice += item.getPrice();
});
}
this.totalPrice = totalSellingPrice;
this.pay.updatePrice(this.totalPrice);
}
// 設置狀態完成對象的初始化
private void init() {
this.status = OrderStatus.CREATED;
}所有流程全部封裝在 Order 的靜態方法 create 上，包括：
- 構建內部實體。根據輸入信息創建 Pay、Address 等關聯實體；
- 金額計算。創建 OrderItem 實體并添加到集合中，在添加流程完成金額計算：
根據單價和購買數量計算 OrderItem 需付金額；
對 OrderItem 需付金額進行累計，更新 Order 的需支付金額；
將 Order 需付金額同步到 Pay 實體；
- 設置訂單狀態。調用 init 方法，將訂單狀態設置為 CREATED；
然后看下改價流程:
public void changePrice(Long newPrice) {
if (newPrice <= 0) {
throw new IllegalArgumentException("金額必須大于0");
}
long discount = getTotalPrice() - newPrice;
if (discount == 0){
return;
}
// Item 均攤折扣
discountForItem(discount);
// Order 折扣
discountForOrder(discount);
// Pay 折扣
syncForPay();
}
// Item 均攤
private void discountForItem(long discount) {
Long totalAmount = getTotalPrice();
Long allocatedDiscount = 0L;
for (int i = 0; i < getOrderItems().size(); i++) {
OrderItem item = getOrderItems().get(i);
Long itemAmount = item.getSellingPrice();
if (i != getOrderItems().size() - 1) {
// 按比例進行均攤
Long itemDiscount = itemAmount / totalAmount * discount;
// 重新設置金額
item.setPrice(item.getPrice() - itemDiscount);
// 記錄累加金額
allocatedDiscount += itemDiscount;
}else {
// 分攤余下的優惠金額到最后一個訂單
Long lastItemDiscount = discount - allocatedDiscount;
item.setPrice(item.getPrice() - lastItemDiscount);
}
}
}
// Order 折扣
private void discountForOrder(long discount) {
Long newTotalPrice = getTotalPrice() - discount;
setTotalPrice(newTotalPrice);
}
// 將價格同步到 Pay
private void syncForPay() {
this.pay.updatePrice(getTotalPrice());
}改價流程由 Order 的實體方法 changePrice 承載，核心流程如下：
- 入參校驗。修改后的金額不可為負數；
- Item金額均攤。按OrderItem金額對折扣信息按比例進行均攤，并更新 Item 上的應付金額；
- Order金額更新。重新計算 Order 應付金額并對金額進行更新（也可以使用所有 Item 的金額總和）；
- Pay金額同步。將Order上的最新金額同步到 Pay 實體；
如此操作，便可以保證聚合根內各個實體對象間的強一致性關系。
那原子能力又體現在哪呢？
- 不可分割。從業務視角，每個操作都是一個不可被拆分的最小執行單元；從技術視角，操作過程不會被打斷；
- 不可破壞規則。必須從一個有效狀態轉換到另一個有效狀態，聚合根內多個實體間的業務規則不允許被破壞；
- 持久化層的原子性保障。整個聚合根的狀態要么全部更新到DB，要么全不更新，不允許只更新部分信息；
聚合根上的這些“原子業務”操作形成了聚合根的生命周期，如下圖所示：
圖片
這是 Order 聚合根的生命周期，每個業務操作均由以下部分組成：
- 業務驗證。包括入參校驗、前置條件校驗；
- 狀態或數據更新。對聚合內實體狀態或數據進行更新；
- 領域事件發布。對外發布領域事件；
以訂單的支付成功為例：
public void paySuccess(){
// 前置校驗
if (getStatus() != OrderStatus.CREATED){
throw new RuntimeException("非待支付狀態，無法操作");
}
// 更新狀態
setStatus(OrderStatus.PAID);
// 如果 OrderItem 需要更新的話進行調用
// paySuccessForItem();
// 發布事件
publishEvent(new OrderPaidEvent(this));
}2.2. 聚合根設計原則
想設計出好的聚合根非常不容易，需要豐富的經驗，更需要對領域概念有很深的認知，但有些原則可以幫助你避免不少坑：
- 盡量簡單。聚合根不應該包含太多的業務對象，應該保持簡單，以保證可維護性；
- 對內部實體提供保護。非聚合根實體或值對象只能通過聚合根來間接訪問，不能被外部直接訪問；
- 業務操作具備原子性。內部實體操作必須滿足聚合根的業務規則，以保證數據的一致性和完整性；
- 謹慎處理與其他聚合根的關系。聚合根不能包含其它聚合根的引用，聚合根之間可以通過 ID 引用來關聯，而不能直接引用其它聚合根，以避免概念的擴大；
- 有效的版本管理。聚合根是狀態變化的載體，為了避免并發情況下狀態不一致，需要有效的版本管理對其進行保障，比如最常見的樂觀鎖機制；
- 具有清晰的職責。聚合根只處理自己的領域問題，不應該處理其它聚合根的領域問題；
2.3. 聚合根的優勢
聚合根的引入會對系統產生非常大的影響，具體如下：
- 簡化系統架構。使用聚合根將整個領域劃分為多個聚合，可以使系統架構更加清晰。每個聚合都有自己的聚合根，聚合根之間只有松散的關聯，這樣可以降低系統的復雜度和耦合度；
- 提高系統性能。聚合根可以作為一組數據的操作單元，因此可以減少數據庫的訪問次數。例如，在多次更新一個聚合后，最終狀態只需要一次數據庫操作便能完成；
- 支持并發處理。使用聚合根可以支持更好的并發處理，聚合是一個最小的操作單元，同一聚合可以使用樂觀鎖等機制來控制并發，而聚合之間不存在共享數據可以進行并行處理；
- 提高可測試性。將整個領域劃分為多個聚合，可以將測試場景限定在單個聚合內，從而提高測試的可控性和可重復性；
3. 流程編排
有了小“積木塊”（聚合根上的原子業務操作），接下來就是如何將其組裝成更大的業務操作。常見的編排方式有：
- 應用服務。對模型中的組件進行編排，為調用者提供完整的業務能力，比如生單、改價等；
- 領域服務。應用服務之下，主要解決跨聚合根操作的業務流程，比如轉賬等；
- 事件編排。應用服務之上，對多個業務域的操作進行編排，實現聚合間、服務間的解耦，比如支付成功后需要給用戶發送短信等；
3.1. 應用服務
應用服務是DDD中重要的一層，它主要根據業務場景對流程進行編排，從而滿足不同場景對領域能力的不同訴求。應用服務位于領域層和接口層之間，對內統一協調多個組件，對外滿足不同場景下的 User Story。
下圖是應用服務所在的位置：
圖片
簡單一句話形容便是：應用服務在領域模型各個組件的能力之上進行流程編排，以滿足上層不同場景下的業務需求。
應用服務使用最多的便是對單個聚合的流程編排，主要包括創建和更新：
創建流程如下：
圖片
更新流程如下：
圖片
兩者最大的區別在于聚合根獲取方式：
- 創建流程，使用工廠完成復雜對象的創建，從而開啟聚合的生命周期；
- 更新流程，使用倉庫從持久化存儲中恢復聚合對象，從而推動聚合生命周期的演進；
那這個的價值在哪呢？因為規范所以可以做到非常好的封裝，具體見代碼：
生單并改價流程編排：
@Transactional
public void createAndChangePrice(CreateOrderAndChangePriceCommand command) {
// 1. 檢查庫存，如果足夠則進行鎖定；如果不夠，則拋出異常
this.inventoryService.checkIsEnoughAndLock(command.getItems());
// 2. 流程編排
// 設置存儲倉庫
creatorFor(this.orderRepository)
// 配置事件發布器
.publishBy(eventPublisher)
// 配置聚合根初始化
.instance(() -> Order.create(command))
// 配置執行額外操作
.update(order -> order.changePrice(command.getNewPrice()))
// 執行操作
.call();
}支付成功流程編排：
@Transactional
public void paySuccess(Long orderId){
// 流程編排
// 設置存儲倉庫
updaterFor(this.orderRepository)
// 設置 id
.id(orderId)
// 配置事件發布器
.publishBy(this.eventPublisher)
// 未找到時拋出異常
.onNotExist(id -> new AggregateNotFountException(id))
// 配置業務動作
.update(order -> order.paySuccess())
// 執行操作
.call();
}代碼的可讀性得到很大的提升。
3.2. 領域服務
領域服務通常是無狀態操作，當一些職責不適合放在任何一個領域對象上時，我們可以考慮將其放在一個領域服務中。
整個流程是一個標準的業務概念，并且流程中涉及多個領域對象，當這個操作放在哪個領域對象上都不合適時，可以將其放在一個單獨的服務中，這個服務就是領域服務。
領域服務只做流程編排，不直接處理業務邏輯，業務邏輯直接調用領域模型中的其他對象。
一個例子就是轉賬，“轉賬”作為一個標準的業務概念，需要提供一個轉賬服務來承載這個領域概念。轉賬服務需要協調兩個領域對象：源賬戶和目標賬戶，源賬號做轉出，目標賬號做轉入，從而實現轉賬邏輯。
簡單的單機場景可以基于數據庫事務進行保障，具體如下：
圖片
image
從嚴格意義上講，在一個事務中只能對一個聚合進行修改，這條原則更適合于分布式系統。在單機系統中，直接使用數據庫本地事務對一致性進行保障，是一種投入產出比極高的事情。
在復雜的分布式場景需要引入“協調器”來對流程進行總控，以實現系統的最終一致性，具體如下：
圖片
image
【注】領域服務只做流程編排，不處理業務邏輯?。。?！
領域服務不會直接暴露給業務方使用，而是由應用服務負責協作。切記應用服務是領域模型的門面（Facade）。
領域服務是基于面向過程編程范式構建的，目的是降低領域模型之間的耦合關系。切記不要被濫用，將太多的邏輯放在領域服務中，這會導致領域服務變得臃腫和難以維護。
3.3. 領域事件編排
領域事件是一種輕量級的通信機制，聚合根可以發布領域事件來通知其他聚合根或外部系統發生了某個事件，而其他聚合根或外部系統則可以訂閱這些事件，進行相應的處理，從而推動流程向下發展。
在系統中，基于領域事件的流程編排極為重要，他是系統間解耦的利器，也是分布式環境下最終一致性的保障。
首先，看一個簡單場景：
圖片
訂單支付成功后，向外發布領域事件，下游接受到領域事件后，做如下動作：
- 為用戶發送購買成功的短信通知；
- 為用戶增加積分；
- 通知倉庫進行發貨；
然后，看一個更復雜的外賣場景：
圖片
在分布式系統中極為常見，將事件串聯起來從而完成一個復雜的業務操作：
- 用戶完成支付，訂單服務向外發布“支付成功”事件；
- 餐廳服務接收到“支付成功”事件后，執行下單動作，將菜品增加到大廚的制菜清單上；
- 餐廳做完菜后對外發送“飯菜準備好”事件；
- 物流系統接收到“飯菜準備好”事件后，通知外賣小哥上門取餐（這點不太合適，應該是支付成功后，快遞小哥便收到通知。為了更好的描述流程，先忽略現實操作）
- 快遞小哥完成取餐、送餐后，物流系統發出“外賣已送達”事件；
- 訂單服務接收到“外賣已送到”事件后，更新訂單為“已完成”狀態；
不管簡單場景還是復雜場景，事件玩的就是一個連線游戲：
- 各個系統已經提供了豐富的業務操作，也就是游戲中的“節點”；
- MQ中間件是一個標準的橋梁，用于連接消息發送方和訂閱方，也就是游戲中的“線”；
- 根據業務流程，將業務操作與消息發送端&消費端鏈接起來，并完成了整個業務操作；
4. 小節
在一個系統中，“元素”的數量是有限的，“元素”間的“關系”是無限的。我們需要用好流程編排這把利器，在有限“元素”基礎上，構建無限的“關系”，從而應對多變的業務場景。
- 原子能力。主要以聚合根為中心，對外暴露的各種 原子業務操作；
- 流程編排。通過多種手段，將原子能力和基礎設施編排起來，最終實現業務需求：
應用服務。對領域模型中的組件進行組裝，以實現不同的業務訴求；
領域服務。對于有明確的業務概念，但找不到合適的領域對象作承載的操作，可以封裝成領域服務；
領域事件編排。主要解決聚合之間、服務之間耦合問題，對于有明確的 “因果” 關系的場景最為實用；
