l

2022年8月17日 星期三

我可能不會用你,Event Sourcing + CQRS?!(下)

August 17 21:54~22:49

截圖 2022-08-17 下午10.07.19

▲圖1:Repository介面

 

前言

在〈我可能不會用你,Event Sourcing + CQRS?!(上)〉Teddy談到Event Sourcing在寫入模型(Write Model/Command Side)並不會比State Sourcing要複雜,甚至更簡單。

但事情通常都是有一好沒兩好,寫入比較簡單,讀取就比較困難,今天討論Event Sourcing在讀取模型的情況。

***

跨Aggregate的資料查詢

在套用DDD(領域驅動設計)之後,Aggregate Root負責發出領域事件,然後透過Repository儲存它的狀態。當採用Event Sourcing時,一個aggregate instance在event store中會有一個event stream用來保存它的所有領域事件。每一個Repository(DDD裡面的Repository設計模式)負責儲存與載入「單一Aggregate」,其介面如圖1所示。

圖2為ezKanban系統core domain的領域模型,它包含Board、Workflow、Card、Tag四個Aggregate。現在問題來了:如何查詢一個Board裡面有多少個workflow?多少張卡片?多少種Tag?」

如果把DDD Repository設計模式定位為「專門在Write Model中用來存取單一Aggregate的介面」,而且Write Model不需要維持「為了查詢而存在的關聯」,那麼在Write Model中,Board並不知道它身上有多少個Workflow以及Tag,而Workflow也不知道它身上每一個Lane有多少張Card。

 

截圖 2022-08-17 下午10.10.36

▲圖2:ezKanban領域模型

 

不用維持雙向關聯之後的Event Sourcing更進一步簡化寫入模型,但查詢就比較困難,特別是針對跨Aggregate之間的查詢。如果不管效率問題,開發人員還是可以透過EventStoreDB內建的Projection功能,讀出領域事件然後在記憶體中「拼出」read model,但這樣執行速度顯然會比較慢。所以在套用Event Sourcing的情況下,針對特別的查詢畫面或報表,通常會特別設計一個View Model以加速讀取速度。

在State Sourcing的情況下,如果是使用關連式資料庫,查詢可以直接下SQL找出所需要的資料。但這並不表示State Sourcing就不會有查詢效率的太慢的問題。同樣地,針對個別查詢畫面,State Sourcing也經常會建立Read Model來加速查詢速度。換句話說,額外建立Read Model並不是Event Sourcing的專利,在State Sourcing系統中,下SQL、Join、Create View都是一種產生Read Model的方法。

***

Event Sourcing到底

傳統上在Event Sourcing系統中套用CQRS,Read Model資料庫的選擇可以和Write Model相同或不同(好像是廢話)。例如Write Model如果用EventStoreDB,Read Model可能用關連式資料庫或NoSQL。但是有另一派的做法是:「既然要Event Sourcing,就Event Sourcing到底,Write Model與Read Model都Event Sourcing。」這是什麼意思?請參考〈事件溯源(11):撰寫JavaScript在EventStoreDB中產生自訂投影〉,Teddy介紹過EventStoreDB可以透過撰寫JavaScript程式讓資料庫自動產生給查詢使用的projection(自訂projection),然後用這些projection來產生Read Model。在這種情況下,Write Database與Read Database就可以合併成一個。

***

 

結論

看到這裡鄉民們可能會覺得:「Teddy你還是沒說Event Sourcing + CQRS是不是比State Sourcing要難啊?」還是那句老話,沒有比較難,只是不一樣。哪裡不一樣:

  • 乍看之下,Event Sourcing寫入比較簡單,讀取比較難,State Sourcing則相反。
  • 實際上則是「能量不滅」,各有各的困難之處。Event Sourcing不須要設計資料庫schema,感覺好棒棒。但設計資料庫schema的問題並沒有消失,只是轉成設計領域事件schema。

Teddy寫這兩篇文章的目的不是要倡導大家使用Event Sourcing,只是要提醒,它就是一種儲存狀態的方式,它沒有比State Sourcing難。如果你找到適合Event Sourcing的應用場景,使用它可以簡化系統設計。如果你的應用場景不需要記錄所有狀態異動,而且你也不熟悉Event Sourcing,那麼就用已經習慣的State Sourcing就好,不用趕流行。

但是,多了解一種狀態儲存方式也沒什麼壞處,難保哪一天合適的應用場景出現了,此時不知道Event Sourcing可能會設計出過於複雜的系統。

***

友藏內心獨白:學習新技術就是為了未來有能力可以看到forces。

沒有留言:

張貼留言