7th DDD book club-Aggregate ＆ Repository

This slide is talking about what and how in Aggregate of DDD. In this slide, you can understand how to design and model an aggregate.

This slide is published in a Taiwanese social community: DDD.tw.

if you are interested in our social community, you can join us, here is our facebook URL:
https://www.facebook.com/groups/dddtaiwan/

Transcript

1. 7th DDD讀書會 聚合完全攻略
2. 大綱 • 聚合概念 • 建模法則 • 重構 • 儲存與提取
3. 聚合的概念 “A collection of objects that are bound together by a root entity, otherwise known as an aggregate root. The aggregate root guarantees the consistency of changes being made within the aggregate by forbidding external objects from holding references to its members.” -- wikipedia
4. 解析聚合的論述 • 以一個Entity作聚合的根物件 • 保障狀態異動的一致性 • 拒絕外部外部直接參考聚合內的成員
5. 衍伸探討 根物件 一致性 防禦性設計 識別碼 不變條件 值物件 建模 尺寸 邊界 實體 交易 ACID 最終一致性 即時一致性 Unit of Work 聚合參考 事件驅動 CAP 屬性檢查 模型檢查 方法參數檢查 • 以一個Entity作聚合的根物件 • 保障狀態異動的一致性 • 拒絕外部外部直接參考聚合內的成員
6. 聚合是高階模式,你需要擁有足夠的底層知識
7. 實體(Entity) “An object that is not defined by its attributes, but rather by a thread of continuity and its identity.” -- wikipedia • 由識別碼來識別不同的實體(Instance) • 由它的狀態異動歷程來區別
8. 實體的精粹 識別碼 異動歷程 • 識別碼在邊界內需為唯一值 • 識別碼的取得方式 • 每個實體的狀態異動歷程都不相同
9. 實體的核心
10. 聚合的實做 聚合本身是一個抽象概念,在實做上,會從聚合中 挑選一個實體作為聚合根(Aggregate Root)
11. 實體與聚合的識別碼設計 實體1 Id 實體2 Id 聚合根1 Id 實體1’ Id 實體2’ Id 聚合根2 Id 搜尋優化: 區域性
12. 實體的儲存 參考資料：https://www.slideshare.net/arafkarsh/event-storming-and-saga
13. 值物件 “An object that contains attributes but has no conceptual identity. They should be treated as immutable.” -- wikipedia • 以所擁有的所有屬性值,作為識別(Conceptual Whole) • 本身具有不可變的特性(Immutable)
14. Immutable帶來的優勢 Side-Effect free
15. 值物件的核心
16. 反思-實體的識別碼 實體的識別碼,其概念含有Immutable特性
17. 以值對象作為實體識別碼 • Allowing for future changes to the underlying identity values without “shotgun surgery”. • Guard against invalid values for identity. • The compiler can help you stop mistakes. • Formatting you Id string for persistent. 參考資料: https://buildplease.com/pages/vo-ids/
18. 防禦性設計 不論是實體/值物件,當狀態需要改變的時候, 都需要驗證新的屬性值是否符合領域的不變性。 聚合需要額外確認自身內部整體的屬性是否符合 領域的不變性。
19. 防禦性設計手法 利用 規格樣式(Specification Pattern)來解決這個問題 檢測邏輯有可能會不斷被重複
20. 大綱 • 聚合概念 • 建模法則 • 重構 • 儲存與提取
21. 建模法則 不可變規則 實體/值物件比例 大小
22. 不可變的規則 • 若一個Backlog Item被提交到Sprint中,那麼我們不能刪除該Backlog Item • 若一個Sprint含有Backlog Item,那麼我們不能刪除該Sprint • 若一個Release中含有Backlog Item,那麼我們不能刪除該Release • 若有一個Backlog Item位於Release中,那麼我們不能刪除該Backlog Item 利用客戶所提的不可變(Invariant)規則進行建模
23. 大聚合 Product BacklogItem Release Sprint <<Entity>> <<Entity>> <<Entity>> <<Aggregate Root>> 1 0…* 0…* 0…* 這個大聚合可能會發生什麼問題?
24. 使用情境 • 使用者Bill和Joe,都獲取到了版本號為1的同一個Product,並且各自開始工作。 • Bill新增並提交(Commit)了一個新的Backlog Item,此時,Product的版本號碼被更新為2 • Joe新增並提交了一個新的Release,當他試著儲存Product時,系統回復錯誤,提示現在的版本號為2 Bill Joe Product V1 Bill Product V1 Product V2 Commit BackdlogItem Joe Product V2 Commit Release
25. 小聚合 BacklogItem <<Aggregate Root>> Product Id <<Value Object>> Release <<Aggregate Root>> Sprint <<Aggregate Root>> Product <<Aggregate Root>>
26. 虛擬碼-從大聚合變成小聚合 工廠方法
27. 優先採用實體還是值物件? 思考實體和值物件的成本
28. 建模原則一、 在一致性邊界內,建模不變條件 不變條件(Invariant)->商業規則(Biz Rule)-> 一致性(Consistent)->交易一致性 在探討的就是交易一致性
29. 簡單一點的方法- 統一語言 A Car where the encapsulated domain objects might be Engine, Wheels, BodyColor and Lights Car Engine Wheel BodyColor Light 先摘出名詞
30. 簡單一點的方法- 統一語言模型法 A Car where the encapsulated domain objects might be Engine, Wheels, BodyColor and Lights Car Engine Wheel BodyColor Light 找出關係
31. 建模原則二、 轉成小聚合 • 一個大聚合會造成效能的問題 • 系統彈性也會降低 轉換期,也是重新思考聚合根的屬性 該使用值物件還是實體? 建議多用值物件。
32. 找小聚合關鍵 BacklogItem <<Aggregate Root>> Product Id <<Value Object>> Release <<Aggregate Root>> Sprint <<Aggregate Root>> Product <<Aggregate Root>> • 每個切出去的聚合要確認其包含的屬性是一個交易內要保持 一致性的 • 不要擔心拆太小,因為多聚合的交易一致性可以使用 最終一致性 的方式來達成。 • 可以借用值物件的Conceptual Whole設計手法
33. 同步操作情境 永遠都要思考同步操作的情境,這是設計小聚合的關鍵
34. 原則三、 一次僅異動一個聚合 對於一個Use Case,是否應該由執行該Use Case的Client來保證資料的一致性? 使用 即時交易一致性 使用 最終交易一致性 兩種交易一致性手法都是僅更新一個聚合
35. 最終一致性與UI/UX 在等待最終一致性的時間內,UI該怎麼顯示資訊?
36. 建模原則四、 參考其它聚合僅引用識別碼 聚合: Product 聚合: BacklogItem
37. 思考一下物件導向的參考方式
38. 評估完整引用 • 聚合減肥尚未成功 • 易犯原則三: 僅異動一個聚合
39. 考量的維度 儲存成本 同步操作 衝突 可能性 大聚合, 完整引用另一個 聚合 大聚合, 完整引用另一個 聚合 小聚合, 完整引用另一個 聚合 小聚合, 僅參考另一個聚合的 識別碼
40. 打破原則三的幾個理由 • User friendly • 缺乏技術機制 • 與遺留系統共舞 • 查詢效能低落
41. 聚合的職責 聚合的方法(Method)設計可以遵循: • SOLID • Law of Demeter
42. 大綱 • 聚合概念 • 建模法則 • 重構 • 儲存與提取
43. 實體升級成聚合根 當有需求異動時,發現到某個實體需要升級成為聚合根 => 添加和調整Repository等物件設計
44. 值物件升級成聚合根 該聚合僅有一個值物件 => 新增一個同名的實體作為聚合根,其內部屬性 為原本的值物件
45. 聚合根降級為實體/值物件 找到更適合擔任聚合根的新概念(實體) => 刪除舊的聚合根所配合的Repository,並創建 新的Repository給新的聚合根使用
46. 聚合根降級為實體/值物件 + 事件朔源 找到更適合擔任聚合根的新概念(實體) => 事件朔源不能僅針對聚合根,需要套用在 聚合中所有實體;當聚合根降級,調整事件處理器 的邏輯
47. 大綱 • 聚合概念 • 建模法則 • 重構 • 儲存與提取
48. 模型的阻抗匹配議題 資料來源:https://my.oschina.net/keking/blog/3009997
49. 資源庫(Repository)的概念 “Methods for retrieving domain objects should delegate to a specialized Repository object such that alternative storage implementations may be easily interchanged.” -- wikipedia • 檢索出領域物件(domain object) – 聚合根 • 可適應各種不同儲存的實現 • 可以輕鬆被替換
50. 若是大聚合 聚合的組成越是複雜,相對的,資源庫的 程式碼也會隨之變得複雜
51. 資源庫的種類 • 集合導向 • 儲存導向
52. 集合導向資源庫的設計 介面參考集合進行設計。
53. 集合導向資源庫的實現 從三個角度思考: • 抽象 • 技術框架 • 領域知識
54. 儲存導向資源庫的設計 為了因應資料庫系統的更換或是儲存方式的易動適應性,考慮採用 儲存導向的資源庫設計。
55. 交易(Transaction) 一個交易操作僅能包含一個聚合。 => 聚合即為一個交易操作的邊界 多個聚合的操作需要利用事件驅動設計來實現。
56. 利用聚合根收集所有領域事件
57. 事件分派 依序觸發聚合根收集的每一個領域事件
58. Recap • 如何設計實體/值物件的識別機制? • 聚合的建模步驟? • 分割小聚合要注意的項目? • 如何創建聚合? • 資源庫建構的三個關鍵? • 聚合與交易