只讀端事件採購/ CQRS數據庫限制

Question

我們公司希望爲我們的財務系統實施事件採購/ CQRS。

對於只讀模型，我們是否應該應用數據庫約束？ 我知道約束不應該在寫事件存儲方。 只讀模型如何？

包括：

• 唯一約束
• 外鍵約束
• 檢查約束
• 默認約束
• 參照完整性

Answer 1

對於只讀模型，我們應該應用數據庫約束嗎？我知道約束不應該在寫事件存儲方面。只讀模型方面如何？

這可能沒有任何用處。

基本上，有兩種情況。一種是讀取模型中的約束與域模型的約束不一致。如果域模型是權威，那麼讀取的模型是錯誤。

另一個是約束是對齊的，但是讀取模型認爲約束被違反，因爲它對發生的事情有不完整的看法。 IE，域模型發出事件[A,B,C,D]，但讀取模型現在只能看到[A,B,C]。

現在，讀取模型中的數據應該被理解爲陳舊;所以只有當新的，一致的域視圖可用時才更新讀取模型並非不合理。

但即便如此，約束應該由數據存儲庫還是由填充存儲的事件使用者來執行仍然不清楚。

我不確定在正常操作期間數據庫限制會爲您購買任何東西。

他們可能在特殊操作中是有用的指導;如果某人試圖「手動」修補讀取模型，那麼在數據庫中擁有冗餘的約束副本可能會防止數據輸入錯誤。 （讀取模型的常見恢復過程是您銷燬緩存副本並重建它;但如果這需要花費相當多的時間，則可以通過修復現有副本來更好地服務您的SLO，直到新副本可用爲止） 。

Answer 2

我在讀取模型上使用db約束。

• FKS與級聯幫助刪除以及告訴你（如果你得到一個例外），你必須在你的應用中的一些情況下結束了不一致的狀態（也許是應用在過去墜毀在一個點和讀取模型未更新）。一輛耐用的公共汽車可以緩解這種情況。
• 默認值只是默認值，我沒有看到問題。
• 我使用唯一約束來達到冪等目的，並在發生違規時忽略它。

您會發現，您可以將db約束用於多種目的，而且它們都與您在寫入模型中使用的業務約束無關。