我開始使用CQRS,我發現我的事件類定義幾乎匹配我的命令定義1。除了顯而易見的代碼重複,我試圖找出我做錯了。肯定有一些情況下,事件不符合命令....但不是很多。CQRS匹配事件和命令
採取簡單的CUD場景:
命令類:
- CreatePost
- UpdatePost
- DeletePost
事件類:
- CreatedPost
- UpdatedPost
- DeletedPost
對此有何建議?
我正在使用事件存儲,如果這有什麼區別。
謝謝。
我開始使用CQRS,我發現我的事件類定義幾乎匹配我的命令定義1。除了顯而易見的代碼重複,我試圖找出我做錯了。肯定有一些情況下,事件不符合命令....但不是很多。CQRS匹配事件和命令
採取簡單的CUD場景:
命令類:
事件類:
對此有何建議?
我正在使用事件存儲,如果這有什麼區別。
謝謝。
您通常不會在CRUD場景中使用CQRS。有更簡單的工具和模式來創建CRUDy應用程序。
CQRS爲行爲豐富的場景帶來很多好處,其中動詞不是創建,讀取,更新,刪除,但更像真實的行爲。像PromoteEmployee或BlacklistVendor。
一旦你開始建模一個行爲豐富的域,可能還有很多核心命令/事件 - 這不是一件壞事 - 但是你也會發現命令和結果事件可能會非常不同大小(包含數據)和數量。
我使用上述作爲一個簡單的例子。上面的CUD操作是包含更復雜命令的更大有界上下文的一部分。即使在那裏,我發現我的活動大部分都是我的命令的重複。 – Jeff 2013-04-09 12:57:28
@傑夫仍然不是一件壞事。你想要什麼事情發生(命令),然後發生(事件)。在很多情況下,這種重複只是現實的反映。並且在這種情況下引入諸如重用之類的東西在這種情況下沒有任何意義,因爲它會與您的系統各部分分離的想法相矛盾。 – 2013-04-09 13:09:00
@Jeff很不幸,你選擇了CRUD作爲例子,這實際上使談話失敗了。 – 2014-09-04 18:32:40
爲了給Dennis Traub的答案增加一點點,CQRS擴展了你如何將你的代碼構造到規範的領域,即UI如何工作。並不是所有的UI都是CQRS友好的;你需要更多沿着Task-based-UI's rather than CRUD-y UI's的路線。
從CRUD-y UI開始,您可能會發現自己在應用CQRS時感到沮喪。
非常好的一點 – 2014-09-05 07:58:16
你可以擴大這個*我想弄清楚我做錯了什麼。*你爲什麼認爲有什麼問題? – 2013-04-23 05:25:47
因爲它看起來像我完全重複代碼沒有什麼好處。 – Jeff 2013-04-23 14:48:07