CQRS項目是否需要類似NServiceBus的消息框架？

Question

最近6個月的學習曲線一直是CQRS和DDD的主要肇事者的挑戰。

它很有趣，我們是通過我們的項目的1/2方式，我沒有時間研究的領域是消息框架。

目前我沒有使用DTC，因此如果我的讀取模型沒有更新，那麼我將在讀取和寫入數據庫之間出現不一致。我的讀寫數據庫也將在同一臺機器上。我懷疑我們會把它們放在不同的機器上。

我的系統中沒有大量消息，所以我的擔心更多的是與系統的一致性和可靠性有關。

那麼，我是否必須放入像NServiceBus這樣的消息框架（即使讀取和寫入數據庫都在同一臺計算機上）還是還有其他選項？是的，有學習曲線，但我想如果我不使用它，會有很多東西需要學習。

而且，我不希望把一個層，如果它是沒有必要的

的思考？

Answer 1

目前所以是一個非常好的可能引擎蓋，如果沒有更新 我讀模型，然後我會不一致 之間的讀取和寫入數據庫，我不使用DTC。

個人而言，我不喜歡DTC，並儘量避免它。相反，通常可以實施補償機制，特別是對於像最終一致性已經可以接受且更新是冪等的讀取模型的東西。例如，你可以在實體上實現一個版本，並有一個後臺任務來確保版本同步。擁有DTC將提供事務性重試功能，但仍不能解決重試後發生故障的情況 - 您仍必須觀察錯誤日誌並制定程序來處理錯誤。

所以，我必須放在一個消息傳遞框架就像NServiceBus（甚至 雖然讀取和寫入數據庫在同一臺機器上）還是我 有其他選擇？

這取決於幾件事。在CQRS系統中經常會遇到的問題是pub/sub需要發佈幾個子系統發佈查詢/緩存系統訂閱的事件。如果你看到了基本的點對點消息傳遞之外的pub/sub需求，那麼請使用類似NServiceBus的東西。另外，即使你不需要它來擴展性，我也不會立即迴避使用NServiceBus，因爲我認爲邏輯分區本身是有益的。另一方面，正如你指出的那樣，增加複雜層次的代價是昂貴的，因此首先試着看看最簡單的事情是否可行。

要問的另一個問題是，你是否需要一個單獨的查詢存儲。如果你只有一臺機器，爲什麼要麻煩？你可以使用像read-model pattern這樣簡單的東西，並且仍然可以從CQRS中獲得很多好處。

Answer 2

CQRS項目是否需要像NServiceBus這樣的消息框架？

簡而言之：沒有。

這是我第一次聽說eulerfx提到的'閱讀模型'。這是一個足夠好的名字，但還有一點點：

「查詢」部分背後的一般想法是查詢數據的非規範化視圖。在'read-model pattern'鏈接中，您會注意到用於填充讀取模型的查詢正在進行一些提升。在上述示例中，所需的數據操作並不複雜，但如果確實變得更復雜？這就是異化進入的地方。當你執行'命令'部分時，下一個操作是對數據進行非規範化並存儲結果以便於閱讀。所有繁重的工作都應該由你的域名完成。

這就是爲什麼你在問消息。這裏有幾種技術：

這是在同一個數據庫中，相同的表
• 非規範化的數據，不同的列
• 非規範化在同一個數據庫中的數據，不同的表
• 在不同的數據庫

非規範化的數據存儲。如何一致性？：

• 立即一致
• 最終一致

最簡單的解決方案（速贏）是在非規範化您的域名數據，然後保存您的域之後通過資源庫對象您立即將denomarlized數據保存到相同的數據存儲，相同的表格或不同的列。 100％一致，您可以立即開始讀取非規格化數據。

如果你真的想你可以創建對象的一個​​單獨的一堆傳輸數據，但它是簡單的只寫一個返回一些數據攜帶您的數據訪問框架提供的對象，一個簡單的查詢層（ .Net的情況，這將是一個DataRow/DataTable）。絕對沒有理由得到幻想。總會有例外，但是你可以繼續寫下一個數據容器。

爲了最終一致性，您需要某種形式的排隊和相關處理。您可以推出自己的解決方案，也可以選擇服務巴士。這是由你和你的時間/技術的限制:)

BTW：我有一個免費的開源服務總線這裏：

• shuttle-esb core
• documentation

任何反饋會受到歡迎。但任何舊的服務巴士都會（MassTransit/NServiceBus /等）。

希望有所幫助。