淺談DDD中的聚合

来源:https://www.cnblogs.com/88223100/archive/2022/09/22/Talking-about-Aggregation-in-DDD.html
-Advertisement-
Play Games

在我看來並不是MVC的基礎上增加領域層,使用充血模型,解耦基礎服務,我的代碼就符合DDD了。 為什麼要使用DDD? DDD分為戰略部分跟戰術部分,相信大家都認同DDD的核心在戰略而非戰術。而戰略方面的核心我認為在業務建模,領域劃分、統一語言等都在為業務建模服務。 為什麼業務建模重要? ... ...


 

 在我看來並不是MVC的基礎上增加領域層,使用充血模型,解耦基礎服務,我的代碼就符合DDD了。

為什麼要使用DDD?

DDD分為戰略部分跟戰術部分,相信大家都認同DDD的核心在戰略而非戰術。而戰略方面的核心我認為在業務建模,領域劃分、統一語言等都在為業務建模服務。

為什麼業務建模重要?

 

以前的開發流程有什麼問題?

先說結論,開發人員交付的程式對業務方,產品人員,測試人員來說就是一個黑盒子。除了開發人員自己,沒人知道盒子里有什麼。當新的需求加入來,需求方,產品人員,甚至測試人員都認為可行,開發人員卻給出相反結論。

回顧一下以前的開發流程 大致可以歸結為以下步驟:(開發跟測試人員最好能參與需求分析)

 

1.業務方描述抽象需求

2.產品將需求轉化為可落地的產品(需求具像化,PRD)

3.開發人員根據產品的PRD開發

4.測試人員根據產品的PRD測試

5.產品人員驗收

6.業務方驗收

依照經驗來說,在整個流程中開發人員是耗時最長的。與此同時測試人員可能在編寫測試用例,而業務方跟產品人員在這段時間內是阻塞的。最終的程式質量靠測試人員來保障。

開發人員完成開發後:

測試人員關註測試用例是否通過。

產品人員確認展現出來的功能是否符合當初的PRD。

業務方確認程式是否符合預期。

舉一個我開發項目的例子

一個審批系統

產品的PRD描述了一個三層模型:

流程實例,流程節點,審批任務。流程實例啟動創建審批節點,審批節點觸發審批任務,任務完成創建下一個節點...。

我是這樣做的:

流程實例,審批任務。流程實例啟動創建(一批)審批任務,任務被完成後創建後續任務或者流程結束。至於流程節點不存在,不是問題,從任務中提取信息虛擬一個出來。

第一版交付完成。

產品在第一版後追加需求

流程節點可以被非審批人評論。

我....

當時業務方,產品,測試都認為這是一個合理的需求。只有我一臉懵,因為我的程式中沒有流程節點這個東西,需求又不能拒絕,無奈給出一個遠超他們預期的開發計劃。

gap就出在 他們認為流程節點是一個確實存在的東西,而只有我知道這節點是虛擬的,沒有標識,不能跟其他信息做關聯。

業務建模怎麼解決這個黑盒子問題?

DDD引入了業務專家這個角色(在我看來就是業務方,產品)。

1.假設業務專家聽不懂 什麼叫類,什麼是方法,設計模式,他只知道他的業務,兩方人馬完全不在同一頻道,這個時候就需要“明確上下文”,“統一語言”了。(不僅僅開發人員與業務專家達成了共識,也包含整個開發團隊達成共識)

2.業務建模,用例分析法、事件風暴、四色建模等看看開始整上。最終達到劃分領域,識別聚合的目的。

3.業務建模落地。開發人員開發過程中,應遵守已經建立的業務模型來編寫代碼。

至此終於實現了,業務專家可通過業務模型窺探到開發人員的代碼實現。統一語言、業務模型在業務專家跟開發人員中間充當了溝通的橋梁。(有點像適配器)

當追加新的需求時,業務專家能合理評估需求的可行性。

讓非開發人員參與到開發中

統一語言,業務建模,模型充血(OOP)。這一系列手段都是為了實現讓非開發人員參與到開發中這一最終目的。與其說DDD是一種架構,不如認為他是指導開發的方法論。

好比蓋房子,以前只要把房子交付了能住人就行。現在業務專家是設計師,業務模型是設計圖,代碼則是建材,程式員就是工地搬磚的,蓋起來的房子得跟設計師給出的設計圖一樣。

業務模型落地的問題?

 

這是一個讓我糾結的問題。我感覺還沒有找到符合我期望的答案。

業務模型具現到代碼中,就是一個個聚合。這些聚合符合OOP的思想,通過聚合根,實體,值對象的組合來表達業務模型。

以網路上常見的demo為例:

//訂單明細實體
public class OrderItemEntity {
  //id
  private Long id;
  //商品(值對象)
  private Product product;
  //數量(值對象)
  private Count count;
  // item總價(值對象)
  private ItemAmount itemAmt;

  public void modifyCount(Count count) {
    this.count = count;
    this.itemAmt = new ItemAmt(this.product.getPrice()*count.get());
  }

}

//訂單聚合根
public class OrderAggregate {
  //聚合唯一標識
  private Long id;
  //訂單號(值對象)
  private OrderNo orderNo;
  //總價 (值對象)
  private Amount amt;
  //訂單明細
  private List<OrderItemEntity> items;

  public void modifyItemCount(Product product,Count count) {
    //找到商品
    this.items.stream().filter(product::equals).findAny().get();
    //修改數量 返回Item總價
    item.modifyCount(count);
    ItemAmount itemAmt = item.getItemAmt();
    //修改訂單總價
    this.amt = new Amount(this.amt.get()+itemAmt.get());
  }

}

//要訂單明細中 名稱叫電腦的商品數量修改100

Product product = new Product("電腦");
Count count = new Count(100);
Amount amt = orderAggregate.modifyItemCount(product, count);

理論與現實的矛盾

 

從代碼上可以看出這一段1:n關係的代碼完全基於記憶體,非常的OOP,也就是說,我們在獲得orderAggregate時,已經載入整個聚合(包括List<OrderItemEntity>),這裡就隱含了一個條件記憶體無限大。

假設OrderItemEntity的量級是十萬級,百萬級,明顯這段代碼是不能上線的,理論與現實出現了矛盾。

 

咨詢了很多大佬+個人理解(以下方法為我自己命名)

 

模型提升法(無限套娃)

大佬建議:

“如果真有這種場景,就需要調整聚合,比如:將OrderItem提升為Order, Order提升為BatchOrder”

思路:

創建BatchOrderAggregate,BatchOrderAggregate持有OrderEntity。

創建OrderAggregate持有部分OrderItemEntity,通過分治的方式化整為零。

思考:

整體上符合業務模型,而且沒有上限,即如果BatchOrderAggregate不能解決問題,那就祭出BatchBatchOrderAggregate。

BatchBatchOrderAggregate持有BatchOrderEntity。

BatchOrderAggregate持有OrderEntity。

OrderAggregate持有部分OrderItemEntity。

持有倉儲法

 

(隱藏了資料庫查詢,但是直覺上有點反模式)

大佬建議:

“聚合中構建索引,需要時再載入置換”

思路:

聚合根持有存儲引用,需要時載入到記憶體中。

可以加入一層介面隔離。

public class OrderAggregate {
  //聚合唯一標識
  private Long id;
  //訂單號(值對象)
  private OrderNo orderNo;
  //總價 (值對象)
  private Amount amt;
  //關聯對象介面(介面實現在基礎服務層,在實現中操作資料庫)
  private OrderItemRel orderItemRel;


 public void modifyItemCount(Product product,Count count) {
    List<OrderItemEntity> items = orderItemRel.find(product);
    //找到商品
    OrderItemEntity item = items.stream().filter(product::equals).findAny().get();
    //修改數量 返回Item總價 這裡有分支,item修改是否應該在modifyCount中持久化
    //1.modifyCount中持久化item那麼資料庫事務將被載入AppcationService層,容易產生大事務問題。
    //2.modifyCount中不持久化item 
    //2.1寫入消息匯流排,當OrderAggregate通過Reponsitory持久化時刷出消息持久化
    //2.2 OrderAggregate中增加List<OrderItemEntity> items,modifyCount將item加入items。
    item.modifyCount(count);
    ItemAmount itemAmt = item.getItemAmt();
    //修改訂單總價
    this.amt = new Amount(this.amt.get()+itemAmt.get());
    return this.amt;
  }
}

自我催眠法

思考:

“持有倉儲法”思路,實現也一致,覺得反模式的原因是:聚合中含有資料庫操作,有耦合基礎服務的嫌疑。

但是換個方向去想:

記憶體也是存儲介質,資料庫也是存儲介質,二者本來沒有質的區別。二者相比只是對於記憶體操作,編程語言直接提供了API,而資料庫訪問需要依賴第三方庫進行額外編碼,假使能將資料庫操作封裝至跟記憶體操作一樣自然,那麼不是不可以讓人接受。

Id關聯法

(感覺上不太符合我的預期,有代碼實現跟業務建模脫鉤,耦合基礎服務的嫌疑。容易退化為MVC,此句屬於本人主觀臆斷)

大佬建議:

“對ddd理解,不能固化。聚合,本意是解決業務操作的一致性。大量文章,都表述為一次性載入,實操中是不現實的。解決 “業務操作一致性”,走 “id關聯+內聚到一個函數+事務控制”,就很好。”

“沒有必要強行ddd,拆分開也沒有什麼問題,通過id關聯就可以。”

“業務建模時按照在同一聚合去建,落地時考慮現實,拆分聚合,通過id關聯。”

 

思考:

 

跟“持有倉儲法”很像,區別可能是在於代碼寫在哪裡,但是這種方法總感覺不是OOP。

聚合拆分法

(我覺得applicationService中應該是跨領域的流程編排,Order,OrderItem有相同的生命周期不能算跨領域,只能算誇聚合。至於domainService,做為領域的一部分,理論上不應該涉及基礎服務,只是存放業務相關但是不適合放在聚合中,也非跨域的代碼)

大佬建議:

“如果OrderItem超過10萬,20萬, 這種情況一般大概率不需要一次性載入出來所有OrderItem,而是分頁載入OrderItem, 這和聚合的特點衝突,建議設計成兩個領域對象單獨管理”

思路:

建立 OrderAggregate跟 OrderItemAggregate兩個聚合,通過領域事件 實現最終一致。

靈活場景法(聚合拆分法Plus)

(感覺還是反模型,代碼好理解,業務專家不一定認可,不像自然語言那樣自然,為了性能做出妥協)

如demo中我們要修改OrderItem的數量,這樣一個場景,場景主體是OrderItem而不是Order,Order被修改可以認為是副作用。

明確場景的情況下(明確上下文) 可以建模為OrderItemAggregate和OrderEntity 將1:n的關係轉化為1:1。

//訂單明細聚合
public class OrderItemAggregate {
  //id
  private Long id;
  //商品(值對象)
  private Product product;
  //數量(值對象)
  private Count count;
  // item總價(值對象)
  private ItemAmount itemAmt;
  //Order實體
  private OrderEntity orderEntity;

  public void modifyCount(Count count) {
    this.count = count;
    ItemAmt itemAmt = new ItemAmt(this.product.getPrice()*this.count.get());
    //order總價
    Amt amt = this.orderEntity.getAmt();
    //總價-item總價+新item總價
    amt = new Amt(amt.get() - this.ItemAmt.get() + itemAmt.get());
    //變更訂單總價
    this.orderEntity.modifyAmt(amt);
    this.itemAmt = itemAmt;
  }

}

//訂單實體
public class OrderEntity {
  //聚合唯一標識
  private Long id;
  //訂單號(值對象)
  private OrderNo orderNo;
  //總價 (值對象)
  private Amount amt;

  public Amount modifyAmt(Amt amt) {
    //修改訂單總價
    this.amt = amt;
  }

}

//要訂單明細中 名稱叫電腦的商品數量修改100
orderItemAggregate.modifyCount(count);

刪除/添加訂單明細同理。

而,訂單支付(訂單被支付)的場景,業務主體是Order(這個場景下OrderItem甚至不會出現修改,當然也就沒有必要載入OrderItem)。

總結

感謝各位大佬提供自己的思路為我解惑。

對與聚合落地,因為最後一種靈活場景變化聚合的思路,完全無關於基礎服務,保持了聚合內的一致性,符合DDD領域只關註業務的思想,而且勉強符合OOP,且落地成本低,從心裡上我更傾向於最後一種方式。唯一的難點在於說服自己他是一個正常的業務模型。

 

作 者 | 李宇飛(菜尊)

本文來自博客園,作者:古道輕風,轉載請註明原文鏈接:https://www.cnblogs.com/88223100/p/Talking-about-Aggregation-in-DDD.html


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 接手的一個項目使用的是avue這個傻瓜式的專門給後端人員用的框架,文檔不夠友好,使用起來各種蛋疼(咱專業前端基本上不使用)。為此,專門記錄一下。當前avue版本2.8.12,如果要切換avue的版本,可以去https://cdn.jsdelivr.net/npm/@smallwei/[email protected] ...
  • REM rem是一個相對尺寸,它相對於html根元素來進行計算 類推3REM為48px。改變html根元素 font-size 屬性的大小。那麼REM值也會隨之改變。 html{ font-size: 50px; /* 預設 16px */ } 此時3REM為150px。接下來我們通過一個小案例來演 ...
  • 我的前端之旅。本節學習CSS媒體查詢(Media Quires),詳細介紹了媒體查詢語法定義,從三個具體佈局例子學習媒體查詢的使用技巧。並介紹了一些scss、css屬性知識。 ...
  • 每日3題 1 以下代碼執行後,控制臺中的輸出內容為? console.log(+true, !'hello') 2 點擊p標簽時,會輸出什麼 const numbers=[1,2,3,4,5] const [y] = numbers console.log(y) 3 以下代碼執行後,控制臺中的輸出內 ...
  • 背景 大家有沒有這麼一種困境 我現在需要去配置一個定時任務:"每天早上九點執行任務" 若你有一個好的定時任務平臺,相信很容易就能配置完成。那若是沒有定時任務平臺呢?是不是就要自己寫cron表達式 那 "每天早上九點執行任務" 的cron表達式怎麼寫呢? 這個時候我會去百度一些cron線上生成,因為我 ...
  • 介紹 在業務中,如果遇到文檔管理類的功能,會出現需要線上預覽的業務需求,本文主要是通過第三方庫來實現文檔預覽功能,並將其封裝成preview組件 docx docx的實現需要使用docx-preview插件 安裝 npm i docx-preview 使用 創建一個容器標簽 <div ref="fi ...
  • ##vue+element-ui後臺管理系統模板 前端:基於vue2.0+或3.0+加上element-ui組件框架 後端:springboot+mybatis-plus寫介面 通過Axios調用介面完成數據傳遞 通過router路由完成各頁面的跳轉 ###全局配置 App.vue <templat ...
  • 外觀模式(facadePattern)又叫門面模式,隱藏了子系統的複雜實現,為子系統中的一組介面提供了一個統一的訪問入口,使得子系統容易被訪問或使用,說白了就是把複雜的子系統封裝成一個介面供給外部用戶更簡單地使用,這也是一種結構型設計模式。 模式結構圖: 此模式中涉及的三種角色: 1、門面角色(Fa ...
一周排行
    -Advertisement-
    Play Games
  • 一:背景 1.講故事 在分析的眾多dump中,經常會遇到各種奇葩的問題,僅通過dump這種快照形式還是有很多問題搞不定,而通過 perfview 這種粒度又太粗,很難找到問題之所在,真的很頭疼,比如本篇的 短命線程 問題,參考圖如下: 我們在 t2 時刻抓取的dump對查看 短命線程 毫無幫助,我根 ...
  • 在日常後端Api開發中,我們跟前端的溝通中,通常需要協商好入參的數據類型,和參數是通過什麼方式存在於請求中的,是表單(form)、請求體(body)、地址欄參數(query)、還是說通過請求頭(header)。 當協商好後,我們的介面又需要怎麼去接收這些數據呢?很多小伙伴可能上手就是直接寫一個實體, ...
  • 許多情況下我們需要用到攝像頭獲取圖像,進而處理圖像,這篇博文介紹利用pyqt5、OpenCV實現用電腦上連接的攝像頭拍照並保存照片。為了使用和後續開發方便,這裡利用pyqt5設計了個相機界面,後面將介紹如何實現,要點包括界面設計、邏輯實現及完整代碼。 ...
  • 思路分析 註冊頁面需要對用戶提交的數據進行校驗,並且需要對用戶輸入錯誤的地方進行提示! 所有我們需要使用forms組件搭建註冊頁面! 平時我們書寫form是組件的時候是在views.py裡面書寫的, 但是為了接耦合,我們需要將forms組件都單獨寫在一個地方,需要用的時候導入就行! 例如,在項目文件 ...
  • 思路分析 登錄頁面,我們還是採用ajax的方式提交用戶數據 唯一需要學習的是如何製作圖片驗證碼! 具體的登錄頁面效果圖如下: 如何製作圖片驗證碼 推導步驟1:在img標簽的src屬性里放上驗證碼的請求路徑 補充1.img的src屬性: 1.圖片路徑 2.url 3.圖片的二進位數據 補充2:字體樣式 ...
  • 哈嘍,兄弟們! 最近有許多小伙伴都在吐槽打工好難。 每天都是執行許多重覆的任務 例如閱讀新聞、發郵件、查看天氣、打開書簽、清理文件夾等等, 使用自動化腳本,就無需手動一次又一次地完成這些任務, 非常方便啊有木有?! 而在某種程度上,Python 就是自動化的代名詞。 今天就來和大家一起學習一下, 用 ...
  • 作者:IT王小二 博客:https://itwxe.com 前面小二介紹過使用Typora+PicGo+LskyPro打造舒適寫作環境,那時候需要使用水印功能,但是小二在升級LskyPro2.x版本發現有很多不如人意的東西,遂棄用LskyPro使用MinIO結合代碼實現自己需要的圖床功能,也適合以後 ...
  • OpenAI Gym是一款用於研發和比較強化學習演算法的工具包,本文主要介紹Gym模擬環境的功能和工具包的使用方法,並詳細介紹其中的經典控制問題中的倒立擺(CartPole-v0/1)問題。最後針對倒立擺問題如何建立控制模型並採用爬山演算法優化進行了介紹,並給出了相應的完整python代碼示例和解釋。要... ...
  • python爬蟲瀏覽器偽裝 #導入urllib.request模塊 import urllib.request #設置請求頭 headers=("User-Agent","Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, l ...
  • 前端代碼搭建 主要利用的是bootstrap3中js插件里的模態框版塊 <li><a href="" data-toggle="modal" data-target=".bs-example-modal-lg">修改密碼</a></li> <div class="modal fade bs-exam ...