CQRS體系結構優化和變化

Question

命令查詢責任分離/事件採購體系結構非常適合我開始的一個項目，該項目每年將涉及與人們的健康保險保險有關的每年約10億筆金融交易。主要優勢包括審計歷史記錄，可擴展性，跨多個團隊實施異步兼容的UI，從讀取數據庫中分離這些事務，通過事件隊列緩解向間歇性連接的現場辦公室傳輸狀態，並應對顯着的業務邏輯變化整個系統的生命週期。

然而，有些地方CQRS/ES將會出現問題，例如爲1億人分配數字ID，最終一致性不可接受的用戶安全性。該系統還有一些CRUD性質的區域，不受CQRS/ES的好處。最後，我們將在不同的團隊和公司中擁有大量開發人員，並且最好能有不需要CQRS/ES能力的領域。是否有可能採用混合方法，其中一些區域不是事件源？我們是否可以同時讀取和寫入兩邊的相關表？

CQRS架構的聚合實體是否簡化了快照緩存失效？任何更新可能被緩存的集合實體的事件都可能被invalidator監聽，並且給定的集合實體比關係實體更粗糙，我們可以區分寫入事件，這個問題是否可以解決？

我期待着每年有大約十億次的活動，需要跟蹤大約四年的歷史。我們可以快照並存檔較早的事件嗎？

是否有度事件採購？例如，一個在線商店系統AddLineItem事件可能包含每個單元的訂單項價格，但依賴於讀取面來在發票上拉取和渲染產品名稱。另一個在線商店可能會在事件數據中包含該名稱。你如何選擇在活動中包含什麼？在健康保險方面，它可能會限制「如果」分析可以運行 - 如果我們沒有包括被保險人的年齡，我們就不可能模擬需要的政策嗎？

有沒有一種有趣的方式來模擬事件的事件？例如，管理員進入系統後，產品的價格將在某個日期發生變化。我想快照將是一個價格時間表。我們可以添加一個後期的ProductPriceChanged事件嗎？運行「假設」情景時，我們是否可以僞造這些事件？ （爲了避免版本號和併發檢測問題，這樣的聚合將不得不很少改變。）通常聲稱CQRS/ES使系統更容易適應未來的業務流程變化。我理解這樣的觀點：命令以無所不在的語言列出事件使得討論和重新配置它們變得更容易，事件採購消除了RDBMS模型的一些僵化。但內會不會發生任何變化，將會打破事件的重播？隨着系統的變化，你會不會得到許多版本化的事件？例如，在網上商店通過更改標準來評估客戶是否爲金卡持有人？你可以拍攝一切嗎？你將如何對這些變化進行後期處理？同樣，你必須小心依賴注入，注入的所有依賴都不會影響業務邏輯，否則你會破壞重放？

任何想法爲什麼它與.NET世界相關聯，在行業的其他領域較少受歡迎程度？

巨大即使只是閱讀也要感謝。

Answer 1

是否有可能採用混合方法，其中一些區域不是事件源？

當然。

我們可以只對同步讀取和寫入雙方相關的表？

在很多情況下，這聽起來像是個壞主意。

待辦事項CQRS架構的總實體簡化快照的緩存失效？

不多？可以用來使緩存無效的記錄簿中發生了一個表示已發生寫入事件的概念，這並不是特別的CQRS想法。這並不簡單 - 只是額外的工作無論如何都在範圍之內。

我們可以快照並存檔較早的活動嗎？

是的，但是......通常情況下，將長壽命實體的歷史分解爲更短的劇集，並將狀態從一個劇集轉移到下一個劇集更容易 - 例如，考慮滾動財務期結束時的分類帳。然後，您將任何已結束的聚合歷史記錄歸檔。

你如何選擇在活動中包含什麼？

查看此聚合所需的狀態以建立/維護/恢復業務不變量。其他一切都可以進去洗。這通常意味着報告（讀取模型）是由多個聚集組成的，並且可能還有文檔。

有沒有一種有趣的方法來模擬事件的事件？

關於事件的事件很混亂。關於流程的活動非常棒。

我們可以改爲添加一個後期的ProductPriceChanged事件嗎？

拼寫錯誤 - 嘗試PriceChangeScheduled。注意：建模時間很重要;領域模型不應該注意時間的流逝，除非外界提到它。

，但不會在事件內的任何更改將中斷事件的重演？

不，但是您需要維護有關事件表示的規則以確保事實如此。 Greg Young正在寫作Versioning in an Event Sourced System作爲電子書。

模式中的快速和髒字段是可選的;你可以添加它們，或刪除它們，但是你永遠不會改變它們的含義。消費者爲他們想要閱讀的任何內容提供默認值，並且「必須忽略」他們不瞭解的條目。

隨着系統的變化，你會不會得到許多版本化的事件？例如，在網上商店通過更改標準來評估客戶是否爲金卡持有人？

不清楚這是什麼問題。可能有幾個事件表示（取決於預期的模式和考慮哪些默認值），但它仍然只是一個事件。系統做出的決定由事件記錄，所以隨着時間的推移並不真正進入。

同樣你必須要小心的依賴注入是不被注入會影響業務邏輯之間的依賴關係，否則你打破重播？

業務邏輯都住在領域模型中，領域模型居住在洋蔥的中心;脫離現實世界。所以你不應該注入任何在現實世界中引入副作用的依賴。這些通常是異步處理的（我們成功保存了這些事件，因此可以計劃副作用）。

任何想法爲什麼它與.NET世界相關聯，在行業的其他領域較少受歡迎程度？

人。 Udi Dahan和Greg Young都有.NET背景。在PHP中也很流行，因爲Mathias Verraes有這樣的背景。

你會怎麼建議我堅持非ES聚合實體？

文檔存儲？ RDBMS？平面文件？ Polyglot持久性很好。

我可能會錯過這回答這個問題 - 如果業務不變是訂單行項目，這是否包括產品名稱或價格？

產品標識和數量可能已足夠。如果您所在的公司的報價可能與目錄中列出的報價有所不同，那麼可能是報價。

我的意思是如果一個聚合的業務邏輯改變，但過去的事件仍然需要處理舊的方式。

一個關鍵的想法是事件的含義不應該改變;他們描述了狀態的變化。所以如果你發現「新版本的事件」意味着不同的事情，那麼你確實有一個新的事件。見楊的書。

聚合業務邏輯 - 決定如何從一個狀態發展到下一個;這確實會改變。但它不會改變給定總量實際所處的狀態。

例如，您可能會發現某些狀態不應該可達。這就是業務邏輯 - 彙總不應該寫入新事件來結束該狀態。這不會以任何方式影響當前處於不可達狀態的聚合;他們仍然存在，因爲那是歷史給他們的地方。通過給他們更多的事件讓他們擺脫這種狀態。