DDD 對決:事務(wù)腳本 vs. 領(lǐng)域模型,哪個才是業(yè)務(wù)優(yōu)化的終極方案?
在 CQRS 架構(gòu)篇提到,由于 Command 和 Query 內(nèi)部驅(qū)動力完全不同,需要在架構(gòu)層就進(jìn)行分離,但其中有個一個原則極為重要:
- “讀”再復(fù)雜也是簡單;
- “寫”再簡單也是復(fù)雜;
可見 Command 遠(yuǎn)比 Query 棘手的多,其中最關(guān)鍵的便是使用哪種模式來承載業(yè)務(wù)?
最常見的業(yè)務(wù)承載模式有:
- 事務(wù)腳本。
- 領(lǐng)域模型。
1. 事務(wù)腳本 與 領(lǐng)域模型
事務(wù)腳本 和 領(lǐng)域模型 都是承載業(yè)務(wù)的不同模型,都有其適合的場景,沒有絕對的對和錯。核心的決策依據(jù)只有一個:選擇最合適的業(yè)務(wù)場景即可。
簡單且直觀的對兩者進(jìn)行區(qū)分:
- 事務(wù)腳本,門檻低上手快,適合簡單的業(yè)務(wù)場景,比如資訊、博客等;
- 領(lǐng)域模型,門檻很高,適合處理復(fù)雜的業(yè)務(wù)場景,比如電商、銀行、電信等;
大家最常聽說也是最反感的便是:被別人稱為 CRUD boy,更多時候說的便是 事務(wù)腳本。
1.1. 事務(wù)腳本
事務(wù)腳本(Transaction Script)是一種應(yīng)用程序架構(gòu)模式,主要用于處理簡單的業(yè)務(wù)場景。它將業(yè)務(wù)邏輯和數(shù)據(jù)庫訪問緊密耦合在一起,以便實現(xiàn)對數(shù)據(jù)的操作。
事務(wù)腳本,將整個業(yè)務(wù)邏輯封裝在一個事務(wù)中,借助數(shù)據(jù)庫事務(wù)來滿足業(yè)務(wù)操作的 ACID 特性。通過將邏輯和事務(wù)封裝在一起,從而簡化應(yīng)用程序的處理和開發(fā)。
下圖是基于事務(wù)腳本的生單流程:
圖片
簡單描述就是:將“腳本”(SQL)進(jìn)行打包,然后放在一個“事務(wù)”中運(yùn)行。這也就是“事務(wù)腳本”命名的由來。
接下來,看一個訂單改價流程:
圖片
和生單流程基本一致,在此不做過多介紹。
1.2. 領(lǐng)域模型
領(lǐng)域驅(qū)動設(shè)計(Domain-Driven Design,DDD)是應(yīng)對復(fù)雜業(yè)務(wù)場景的利器,它是對業(yè)務(wù)領(lǐng)域中的關(guān)鍵概念和業(yè)務(wù)規(guī)則的抽象。領(lǐng)域模型是一個對象模型,它主要描述各領(lǐng)域?qū)ο笾g的關(guān)系和行為。
和事務(wù)腳本不同,領(lǐng)域模型使用對象來承載業(yè)務(wù)邏輯,領(lǐng)域模型的設(shè)計基于業(yè)務(wù)領(lǐng)域知識,強(qiáng)調(diào)領(lǐng)域?qū)<业膮⑴c,以提高軟件系統(tǒng)的質(zhì)量和開發(fā)效率。
下圖是基于領(lǐng)域模型的生單流程:
圖片
簡單描述就是:核心業(yè)務(wù)邏輯全部由對象實現(xiàn)(addItems方法),數(shù)據(jù)庫僅做數(shù)據(jù)存儲。
接下來,看下基于DDD的訂單改價流程:
圖片
和生單流程基本一致,核心邏輯由 Order 的 modify price 實現(xiàn)。
相比之下,領(lǐng)域模型就復(fù)雜太多,它由多個實體 (Entity)、值對象 (Value Object)、聚合 (Aggregate)、領(lǐng)域服務(wù) (Domain Service)、工廠 (Factory) 等組成,它們共同構(gòu)成了領(lǐng)域?qū)ο竽P?。在模型中,實體和值對象表示業(yè)務(wù)中的實際對象,聚合是由多個高內(nèi)聚實體和值對象形成的組合提,領(lǐng)域服務(wù)表示不屬于任何一個實體或值對象的操作,工廠則用于創(chuàng)建復(fù)雜的對象,比如實體和值對象等。
1.3. 區(qū)別
兩者都是承載業(yè)務(wù)邏輯的架構(gòu),但區(qū)別巨大:
- 事務(wù)腳本是以流程為中心的設(shè)計方法,在數(shù)據(jù)庫層面執(zhí)行指令,簡化數(shù)據(jù)處理的過程;DDD 是以領(lǐng)域?qū)ο鬄橹行牡脑O(shè)計方法,旨在更好地理解和解決業(yè)務(wù)問題。
- 事務(wù)腳本以技術(shù)和流程為重點,以技術(shù)為中心,以代碼實現(xiàn)為核心,關(guān)注數(shù)據(jù)處理問題;DDD 則強(qiáng)調(diào)模型驅(qū)動開發(fā),以業(yè)務(wù)為中心,以領(lǐng)域模型為核心,關(guān)注業(yè)務(wù)邏輯,并以此為基礎(chǔ)進(jìn)行技術(shù)實現(xiàn)。
- 事務(wù)腳本很容易造成代碼的累積,難以維護(hù);DDD 能夠幫助開發(fā)人員找到領(lǐng)域的本質(zhì)(深層模型),并以此為核心,從而形成統(tǒng)一的、易于維護(hù)的架構(gòu)。
除此之外,DDD 還有很多的特點,比如:
- 標(biāo)準(zhǔn)化。DDD 由一組嚴(yán)謹(jǐn)?shù)囊?guī)范組成,有完整的理論基礎(chǔ),可以實現(xiàn)落地過程的標(biāo)準(zhǔn)化;
- 設(shè)計模型。大家在日常工作中很少使用設(shè)計模型的根因在于:缺乏應(yīng)用場景。當(dāng)你處于“過程式”的開發(fā)模式下,只能產(chǎn)出面條代碼;只有面對“面對對象”場景,才能落地設(shè)計模式,提升抽象能力;
- 降維打擊。DDD 是從業(yè)務(wù)需求出發(fā),將業(yè)務(wù)概念轉(zhuǎn)化為對象模型,最后通過技術(shù)進(jìn)行落地。這本身就是一種自上而下的設(shè)計方式,聚焦于業(yè)務(wù),解決真實問題;
2. 實戰(zhàn)體驗
對于程序員來說,文字顯得不夠直觀,在此我們通過代碼來體驗下兩者的不同。
為了更好的體現(xiàn)兩者的區(qū)別,將會從兩個場景進(jìn)行對比:
- 創(chuàng)建場景。圍繞電商下單流程進(jìn)行說明。
- 更新場景。以電商訂單改價流程為基礎(chǔ)進(jìn)行說明。
在日常開發(fā)中,物理刪除場景用的非常少,甚至很多公司都明令禁止使用“delete”語句。通常使用 “邏輯刪除” 替代,它可歸屬為標(biāo)準(zhǔn)的更新場景,在此暫不對比 物理刪除場景。
2.1. 創(chuàng)建場景:下單
在電商中,一個標(biāo)準(zhǔn)的下單需求主要包括:
- 對商品庫存進(jìn)行校驗,避免出現(xiàn)超賣的情況;
- 對商品庫存進(jìn)行鎖定,如果支付成功則直接扣減鎖定的庫存;如果支付失敗,則對鎖定的庫存進(jìn)行歸還;
- 為每一種購買的商品生成一個訂單項(OrderItem),記錄商品單價、購買數(shù)量、需付總價、應(yīng)付金額等;
- 為每一筆下單生成一個訂單(Order),記錄用戶、地址、支付金額、訂單狀態(tài)等;
2.1.1. 基于事務(wù)腳本的下單
核心代碼如下:
@Transactional
public void createOrder(CreateOrderCommand createOrderCommand) {
// 1. 庫存校驗
for (OrderItemDTO itemDTO : createOrderCommand.getItems()) {
Integer stock = inventoryMapper.getStock(itemDTO.getProductId());
if (stock < itemDTO.getQuantity()) {
throw new IllegalStateException("庫存不足");
}
}
// 2. 鎖定庫存
for (OrderItemDTO itemDTO : createOrderCommand.getItems()) {
inventoryMapper.lockStock(itemDTO.getProductId(), itemDTO.getQuantity());
}
// 3. 生成訂單項
List<OrderItem> items = createOrderCommand.getItems().stream()
.map(OrderItem::create)
.collect(Collectors.toList());
orderItemMapper.createOrderItems(items);
// 4. 生成訂單
Long totalPrice = items.stream()
.mapToLong(OrderItem::getPrice)
.sum();
Order order = new Order(createOrderCommand.getUserId(), totalPrice, OrderStatus.CREATED);
orderMapper.createOrder(order);
}
事務(wù)腳本與需求所需操作流程完全一致,簡單來說就是使用“編程語言”對需求進(jìn)行了翻譯。
2.1.2. 基于 DDD 的下單
核心代碼如下:
public void createOrder(CreateOrderCommand createOrderCommand) {
// 1. 檢查庫存,如果足夠則進(jìn)行鎖定;如果不夠,則拋出異常
this.inventoryService.checkIsEnoughAndLock(createOrderCommand.getItems());
// 2. 創(chuàng)建 Order 聚合,此處使用靜態(tài)工廠創(chuàng)建復(fù)雜的 Order 對象
Order order = Order.create(createOrderCommand);
// 3. 保存 Order 聚合, @Transactional 在OrderRepository上
this.orderRepository.save(order);
}
public class Order {
private Long id;
private Long userId;
private Long totalSellingPrice = 0L;
private Long totalPrice = 0L;
private OrderStatus status;
private List<OrderItem> orderItems = new ArrayList<>();
// 避免外部調(diào)用
private Order(Long userId) {
this.userId = userId;
}
// 靜態(tài)工廠,封裝復(fù)雜的 Order 創(chuàng)建邏輯,并保障創(chuàng)建的 Order 對象是有效的
public static Order create(CreateOrderCommand createOrderCommand) {
Order order = new Order(createOrderCommand.getUserId());
order.addItems(createOrderCommand.getItems());
order.init();
return order;
}
// 添加 OrderItem,并計算總金額
private void addItems(List<OrderItemDTO> items) {
if (!CollectionUtils.isEmpty(items)){
items.forEach(item ->{
OrderItem orderItem = OrderItem.create(item);
this.orderItems.add(orderItem);
this.totalPrice += item.getPrice();
});
}
this.totalPrice = totalSellingPrice;
}
// 設(shè)置狀態(tài)完成對象的初始化
private void init() {
this.status = OrderStatus.CREATED;
}
}
和事務(wù)腳本相比,由以下幾點不同:
- 應(yīng)用服務(wù)中的 createOrder 方法內(nèi)容非常簡單,可以看做是模版代碼,變化的可能性非常小,可以對其進(jìn)行進(jìn)一步的封裝;
- 核心邏輯全部在 Order 聚合根中,通過靜態(tài)方法 create 完成 Order 對象的創(chuàng)建,業(yè)務(wù)邏輯非常集中,形成了擁有屬性和行為的“富對象”;
- 數(shù)據(jù)操作與邏輯解耦,最后一步操作 orderRepository#save 方法 完成內(nèi)存對象向DB數(shù)據(jù)的同步,其他部分均不涉及基礎(chǔ)設(shè)施;
2.2. 更新場景:訂單改價
在電商中,訂單改價主要包括:
- 修改訂單項價格(OrderItem),根據(jù)商品要支付金額對新價格按比例進(jìn)行均攤;
- 修改訂單價格(Order),修改訂單的支付金額;
2.2.1. 基于事務(wù)腳本的訂單改價
核心代碼如下:
@Transactional
public void changeOrderPrice(Long orderId, Long newPrice) {
// 1. 校驗金額
if (newPrice <= 0) {
throw new IllegalArgumentException("金額必須大于0");
}
// 校驗訂單有效性
Order order = orderMapper.getOrderById(orderId);
if (order == null) {
throw new IllegalArgumentException("訂單不存在");
}
// 2. 對訂單項價格進(jìn)行均攤
allocateDiscount(order, order.getTotalPrice() - newPrice);
// 3. 修改訂單價格
order.setTotalPrice(newPrice);
orderMapper.updateOrder(order);
}
public void allocateDiscount(Order order, Long discount) {
if (discount == 0){
return;
}
List<OrderItem> items = this.orderItemMapper.getByOrderId(order.getId());
Long totalAmount = order.getTotalPrice();
Long allocatedDiscount = 0L;
for (int i = 0; i < items.size(); i++) {
OrderItem item = items.get(i);
Long itemAmount = item.getSellingPrice();
if (i != items.size() - 1) {
// 按比例進(jìn)行均攤
Long itemDiscount = itemAmount / totalAmount * discount;
// 重新設(shè)置金額
item.setPrice(item.getPrice() - itemDiscount);
// 記錄累加金額
allocatedDiscount += itemDiscount;
}else {
// 分?jǐn)傆嘞碌膬?yōu)惠金額到最后一個訂單
Long lastItemDiscount = discount - allocatedDiscount;
item.setPrice(item.getPrice() - lastItemDiscount);
}
// 更新數(shù)據(jù)庫
this.orderItemMapper.update(item);
}
}
和所描述的操作流程完全一致,成功使用“編程語言”完成了對需求的翻譯。
2.2.2. 基于 DDD 的訂單改價
核心代碼如下:
@Transactional
public void changeOrderPrice(Long orderId, Long newPrice) {
// 1. 校驗金額
if (newPrice <= 0) {
throw new IllegalArgumentException("金額必須大于0");
}
// 2. 獲取訂單聚合根
Optional<Order> orderOpt = this.orderRepository.getById(orderId);
Order order = orderOpt.orElseThrow(() -> new IllegalArgumentException("訂單不存在"));
// 3. 修改價格
order.changePrice(newPrice);
// 4. 保存 Order 聚合
this.orderRepository.save(order);
}
// Order 聚合根內(nèi)方法
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);
}
// 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) {
// 按比例進(jìn)行均攤
Long itemDiscount = itemAmount / totalAmount * discount;
// 重新設(shè)置金額
item.setPrice(item.getPrice() - itemDiscount);
// 記錄累加金額
allocatedDiscount += itemDiscount;
}else {
// 分?jǐn)傆嘞碌膬?yōu)惠金額到最后一個訂單
Long lastItemDiscount = discount - allocatedDiscount;
item.setPrice(item.getPrice() - lastItemDiscount);
}
}
}
// Order 折扣
private void discountForOrder(long discount) {
Long newTotalPrice = getTotalPrice() - discount;
setTotalPrice(newTotalPrice);
}
和生單流程一樣:
- 應(yīng)用服務(wù)中的 changeOrderPrice 方法內(nèi)容非常簡單,標(biāo)準(zhǔn)的模版代碼,變化可能性非常小,需要對其進(jìn)行封裝;
- 核心邏輯全部在 Order 聚合根中,通過 changePrice 方法 完成改價邏輯,業(yè)務(wù)邏輯非常集中,形成擁有屬性和行為的“富對象”;
- 數(shù)據(jù)操作與邏輯解耦,最后一步操作 orderRepository#save 方法 完成內(nèi)存對象向DB數(shù)據(jù)的同步,其他部分均不涉及基礎(chǔ)設(shè)施;
2.3. 對比
看過這兩種風(fēng)格代碼有什么感覺?你可能會說代碼也沒少些什么,只是組織方式發(fā)生了變化。
確實是,只是組織方式發(fā)生變化,代碼一行都沒少。這是這點變化,帶來了革命的創(chuàng)新。
來看個新的場景:業(yè)務(wù)改價過于隨意,產(chǎn)品想增加一個環(huán)節(jié):填入改價金額后,先把每個訂單項的均攤價格展示出來,確認(rèn)無誤后在提交改價請求。
在不同的模式下,又該怎么解呢?
- 事務(wù)腳本模型下,大概率會 copy 一個新的 changePrice,并在其基礎(chǔ)上進(jìn)行修改。這將產(chǎn)生代碼的冗余,比如原來 changePrice 方法存在bug,在修復(fù)時你需要修改多處,但往往只會想起一處;
- DDD模型下,你只需獲取 Order 聚合,然后調(diào)用 changePrice 方法,把均攤結(jié)果進(jìn)行返回,便可實現(xiàn)想要的結(jié)果;
3. 小節(jié)
事務(wù)腳本 和 領(lǐng)域模型 是承載業(yè)務(wù)的不同模式,都有各自適用的場景,需要根據(jù)自己的需求進(jìn)行選擇。
事務(wù)腳本:流程 + 數(shù)據(jù),在操作流程中對數(shù)據(jù)進(jìn)行操作;
領(lǐng)域模型:編排 + 模型 + 數(shù)據(jù),基于模型能力進(jìn)行編排,以完成業(yè)務(wù)操作;操作結(jié)果暫存于對象中,最后將其同步到數(shù)據(jù)庫;
DDD 靈活性還體現(xiàn)在:
- 流程組合,添加一個新功能,一次性完成生單和改價操作;
- 封裝不變,創(chuàng)建和更新主流程基本一致,可以對其進(jìn)行封裝,以統(tǒng)一操作;
- 應(yīng)用模式,邏輯由聚合對象承接,各種模式都可以拿來使用,比如設(shè)計模式、架構(gòu)模式、領(lǐng)域模式等;
- 局部標(biāo)準(zhǔn)化,基于 DDD 戰(zhàn)術(shù)體系,構(gòu)建標(biāo)準(zhǔn)的編程模型;
想了解 DDD 的精髓,讓我們進(jìn)入下一篇:初識極簡DDD。