我可能不會用你，Event Sourcing + CQRS？！（下）

August 17 21:54~22:49

▲圖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。

 

▲圖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。