CQRS跟蹤用戶的變化

Question

我們目前正在研究構建我們的（網絡）應用程序的新方法，並且提到的一種方法是CQRS。我們對此仍有幾個問題：

如果我理解正確的話這可能意味着具有2米或多個域的模型，一個核心域模型和webapp的一個讀模式。

此核心域模型不是直接由webapp寫入，而是由不同的服務寫入。 我們正在考慮使用NServiceBus來創建發佈者/處理程序，以便webapp可以發佈用戶所做的更改。然後用戶將處理該消息並更新核心域模型和讀取模型。

我們要實現什麼：

用戶A創建了10個新的對象，書的例子。

消息的用戶有很多信息的處理，因此需要一兩分鐘被更新的域模型前。

當用戶A刷新頁面時，他應該看到他剛剛創建的10本書。

當用戶B刷新頁面時，他並不一定要看到這些項目。

你在哪裏最好的商店，這些10個新對象？

將此數據與讀取模型中的「舊」數據合併的最佳方式是什麼？

比方說，用戶B也需要看到這些新項目，什麼是存儲這些數據的最佳方式呢？

什麼是最好的方式來處理由2個不同的用戶在同一時間添加同一本書？ （其中所有數據都是相同的，除了這本書描述。它仍然是同一本書:)

有什麼辦法可以處理更新還未被寫入到核心領域模型這10個對象之一併因此沒有唯一的ID？

Answer 1

在我看來 CQRS有很多不同的方面需要考慮。我從中解脫出來的核心是用戶行爲（命令 - >寫模型）和顯示信息（查詢< - 讀取模型）的分離。然後，我可以根據應用程序的要求選擇適當的自然適合該架構模式的其餘架構模式。請記住，CQRS並不是頂級架構，您應該從中選擇並僅在適當的時候使用。

從你的問題，我給你還沒有，所以我推薦以下很遠你的研究得到的印象; Initial CQRS documentation,Rinat Abdullin's Blog,Jonathan Olivers Blog (read the older stuff)和Rinat's CQRS guide (although I've yet to read through this site)。

我保證已經通過CQRS documentation讀，你就可以回答你的問題自己。

也許如果您告訴我們您希望使用的模式/技術，我可以提供更完整的答案。但爲了讓你的第一個問題開始，它是非常簡單的：

你最適合存儲這10個新對象的地方在哪裏？

答案是邏輯上你存儲部分數據的在寫和讀模式;在物理上這可以存儲在相同的數據存儲區或不同的數據存儲區，具體取決於您選擇的技術和實現（例如，sql-server數據庫vs鍵值no-sql解決方案）。

例如，如果您選擇使用事件源，那麼您將事件存儲在寫入模型中。您的閱讀模型將存儲非規格化的數據，製作成您的屏幕可以由您閱讀模型的這些數據組成。但是，正如我所看到的那樣，這一切都保持真實。您的讀取模型可以存儲您的查詢服務通過對關係數據庫執行實際的sql查詢而標準化的數據。

編輯如下評論

我目前工作雖然它使用的事件不使用通訊系統。一切都是進程中。因此，命令被處理;事件在同一工作單元內提出和處理。基本上，命令處理程序不會完成，直到適當的事件處理程序全部完成。

當讀取模型存在更多密集/複雜更新時，我們仍在考慮進程外處理事件處理程序。但是在這個階段不需要它，它使事情變得簡單。

整個最終一致性方面只是模式的一部分。對於其他用戶來說，這絕不會是一個問題，但對於剛剛提交然後刷新頁面的用戶而言，我可以看到這讓他們感到困惑，從而看不到他們剛剛提交的更新。就我個人而言，我不喜歡僞造更新的想法，因爲它像是在努力上加倍。相反，我更喜歡重定向到確認頁面的選項，爲應用程序提供更多時間來處理消息。

我個人希望進一步探究的東西是追蹤提交的命令，並關聯進程外事件處理程序。刷新頁面的用戶尚未完成消息時，可能會收到未完成消息的通知。一旦消息完成處理，可以將通知「推送」給客戶端。我會讓這些通知變得微妙，以免讓用戶分心，或者變得煩人和不方便。