整個系統事件爲什麼會出現反模式？

Question

我目前正在設計一個新的企業系統。該系統的目的是跟蹤，顯示並通知員工與公司的客戶交互（即事件）。使用事件源模式來保存收集的所有客戶交互/事件的分類帳似乎非常合適，因爲我們所有的附加域對象都是從事件流派生而來的。但是，我發現一篇文章說，基於事件採購的整個系統是一種反模式。爲什麼會這樣？

https://www.infoq.com/news/2016/04/event-sourcing-anti-pattern

Answer 1

文章確實總結了格雷格的談話「DDD，CQRS，事件採購的十年」在DDD歐洲2016

我個人不喜歡這個總結的標題，因爲這絕對不是Greg的談話點。基本上像往常一樣，它取決於。

當Greg談到系統時，他意味着整個事情。這個東西，在DDD術語，有一個上下文映射，有多個有界上下文。通常，在此上下文映射中，您可以識別子域，其中一個或多個子域可以另外標識爲核心域。

當你擁有自己的核心領域時 - 將會非常適合先進技術，這將會是更傳統的DDD戰術模式，比如聚合，還是像事件採購這樣的「fancier」。實施確實需要基於情境需求。

從您的描述來看，您非常適合採用事件採購。但是您可能會考慮系統的其他部分，例如客戶/聯繫人管理和員工管理。這些細節應該來自某處。可能是這些是CRUD的候選人？因此，如果您的核心領域是爲了跟蹤員工與客戶之間的交互，某種類型的客戶關係管理，您可以決定使用不太先進的技術使用Event-Sourcing和其他部分系統構建該部分。

請記住，無論如何，包括外部系統放在上下文映射的所有部分，那麼你會看到系統字的意思是在文章和談話。

Answer 2

文章引用由Greg Young的談話。相關部分可見here.

Young解釋說CRUD隱藏了「各種瘋狂用例」，並給出了糾正拼寫錯誤的例子。

他還指出，在事件源系統中分析可能會更加昂貴。

一般來說，將不可變事件作爲系統給定部分的真值來源（與讀取的模型分離）會帶來成本，不應盲目採用。

年輕人認爲「更像事件驅動的東西」將是一個頂級架構，而不是CQRS /事件採購。