事件源：聚合根和性能

我正在使用事件源構建StackOverflow克隆。 MVP的很簡單：事件源：聚合根和性能

用戶可以張貼問題
用戶可以回答的問題
用戶可以給予好評和downvote的答案非封閉式問題

我建模的問題作爲聚合根。一個問題可以有零個或多個答案，答案可以有零個或多個upvotes和downvotes。

雖然這會導致巨大的性能問題。爲了答覆答案，必須加載問題（作爲聚合根），這需要加載所有的答案。在非事件源DDD中，我會使用延遲加載來解決這個問題。但事件採購中的延遲加載並非微不足道（http://docs.geteventstore.com/introduction/event-sourcing-basics/）

將問題建模爲聚合根是否正確？

來源

2015-12-29 MattTannahill

Vernon似乎建議這些應該是多個聚合，以避免併發問題：http://ptgmedia.pearsoncmg.com/images/9780321834577/samplepages/0321834577.pdf – MattTannahill

不，你沒有建模一個聚合根。你'建模'一個數據結構/視圖模型，並稱之爲'聚合根'。正確的DDD沒有這個問題，這是最常見的DDD錯誤之一。您的模型完全錯誤，您需要再次嘗試確定聚合及其一致性規則。順便說一句，通常CQRS是性能的答案，但在這種情況下，模型仍然是錯誤的，無論cqrs。 – MikeSW

感謝您的反饋。我發現了Vaughn Vernon這個非常有用的例子：https://github.com/VaughnVernon/IDDD_Samples/tree/05d95572f2ad6b85357b216d7d617b27359a360d/iddd_collaboration/src/main – MattTannahill

首先不要使用延遲加載（使用ORM時）。因此，你可能會遇到更糟糕的情況，而不是等待一段時間。如果你需要使用它，大部分時間意味着你的模型只是錯誤的。

你可能要考慮的東西象下面這樣：

多少答案你期望的問題。
如果有人在提交自己的答案時發佈了答案，會發生什麼情況。 upvotes也一樣。
upvote只是簡單的+1而你不再關心它，或者你可以找到所有upvotes爲用戶，例如改變他們downvote（upvotes被確定）。

您可能想要單獨聚合，不是因爲性能問題，而是因爲併發問題（問題2）。

根據性能和upvote的行爲方式，您可能會考慮將其建模爲值對象。（問題3）

來吧，read ithttp://dddcommunity.org/library/vernon_2011/

真實表現打你可以通過使用CQRS實現讀/寫分離 http://udidahan.com/2009/12/09/clarified-cqrs/

來源

2015-12-29 22:37:45 Dariss

感謝弗農提示。他的書很有啓發性，GitHub上的例子是非常有幫助的。 – MattTannahill

用一個簡單的模型讀取它不應該是一個問題。問題的最大答案是多少？也許有幾百個與非規格化數據模型沒什麼大不了的。

upvote事件將由具有少數屬性的非常簡單的命令觸發。

事件處理程序很可能必須加載整個問題。但通過聚合根ID加載這些記錄並重放事件非常快。如果每個問題的事件數量非常高（由於回答編輯等），您可以實現快照而不是重播每一個事件。並且該過程異步完成，這將使讀取模型與事件存儲「最終一致」。

來源

2016-01-11 07:46:30

事件源：聚合根和性能

回答

相關問題