建築問題

Question

由於一前一後（Architecture: simple CQS）的結果，我一直在想，我怎麼能建立一個簡單的系統，該系統可以靈活地後來擴展。換句話說：我現在看不到需要成熟的CQRS，但是如果需要的話，我希望以後能夠很容易地演化成它。

所以我就想來分隔查詢命令，但都基於相同的數據庫上。

查詢部分很簡單：基於視圖的WCF數據服務很容易查詢數據。沒有什麼特別的。

命令部分是更困難的事情，這裏有一個想法：命令當然是以異步方式執行的，所以它們不會返回結果。但是，我的ASP.NET MVC站點的控制器通常需要來自命令的反饋（例如，如果成員的註冊成功與否）。所以如果控制器發送一個命令，它也會生成一個與命令屬性一起傳遞的事務ID（一個guid）。命令服務接收到該命令，將其放入狀態爲「處理」的數據庫中的事務表中，並執行（使用DDD原則）。執行後，事務表被更新，以便狀態變爲「完成」或「失敗」，以及其他更詳細的信息，例如生成的主鍵。

與此同時，該網站正在使用QueryService來查詢此事務的狀態，直到它收到「已完成」或「失敗」，然後它可以基於此結果繼續其工作。如果事務表被輪詢並且結果「完成」或「失敗」，則該條目被刪除。

副作用是我不需要guid作爲我的實體的鍵，這對性能和大小來說是件好事。

在大多數情況下，可能不需要此輪詢機制，但如果需要的話是可能的。接口的設計考慮到CQS，所以對未來開放。

你認爲在這種方法的任何缺陷的？其他想法或建議？

謝謝！

路德

Answer 1

我覺得你很接近滿CQRS的系統與方法。

我有我用來做類似於你所描述的東西的網站。我的網站braincredits.com採用CQRS架構，所有命令本質上都是異步的。所以，作爲一個結果，當我創建一個條目，確實沒有反饋到除命令以外的用戶已成功處理（不在於它處理）提交。

但我在網站上有一個用戶評分（他們的「評分」），應該隨用戶提交更多的項目而改變。但我不希望用戶繼續點擊F5刷新瀏覽器。因此，我正在做你正在提出的建議 - 我有一個AJAX調用，每隔一兩秒就會觸發一次，以查看用戶的信用計數是否已更改。如果有的話，新的數量會被帶回並更新用戶界面（有一點動畫可以吸引用戶的注意 - 但不會太浮華）。

你說的是最終的一致性 - 用戶看到的應用程序的狀態最終將與系統數據（記錄系統）一致。這個概念對於CQR​​S來說非常關鍵，並且在我看來，這很有意義。只要您在系統中檢索數據（無論是否是基於CQRS的數據），數據都是舊的。但是，如果你假設客戶端最終會保持一致，那麼你的方法是有道理的，你也可以設計你的UI來解決這個問題，並利用它。

就建議而言，我會觀察你做了多少民意測驗，以及你發送和接收多少數據。不要過度投票，這聽起來像你不是。但是，要定期在您的網站上更新哪些內容，我認爲您會很好。

查詢端的WCF數據服務層是一個好主意 - 只要確保它只能讀取（我相信你已經完成了）。

除此之外，這聽起來像你是一個良好的開端。

我希望這會有所幫助。祝你好運！