event-sourcing - 为什么整个系统事件溯源是一种反模式？

Question

我目前正在设计一个新的企业系统。该系统的目的是跟踪、显示和通知员工客户与公司的互动(即事件)。使用事件源模式来保存正在收集的所有客户交互/事件的分类帐似乎非常合适，因为我们所有的附加域对象都源自事件流。然而，我看到一篇文章说基于事件溯源的整个系统是一种反模式。为什么会这样？

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

Answer 1

这篇文章确实是对 Greg 在 DDD Europe 2016 上的演讲“DDD、CQRS、事件溯源的十年”的总结。

我个人不喜欢这个总结的标题，因为这绝对不是 Greg 演讲的重点。基本上，像往常一样，这取决于。

当 Greg 谈到 系统 ，他的意思是全部。这个东西，用 DDD 术语来说，有一个上下文映射，有多个有界上下文。通常，在此上下文 map 上，您可以识别子域，其中一个或多个可以另外识别为核心域。

当您拥有核心领域时 - 将非常适合高级技术，这将是更传统的 DDD 战术模式(如聚合)，还是“更高级”的东西(如 Event-Sourcing)。实现确实需要基于上下文的需要。

根据您的描述，您非常适合事件溯源。但是您可能会考虑系统的其他部分，例如客户/联系人管理和员工管理。这些细节应该来自某个地方。可能这些是 CRUD 候选人？因此，如果在这种情况下您的核心领域是跟踪员工和客户之间的交互，某种 CRM，您可以决定使用事件溯源来构建该部分，并使用不太先进的技术构建系统的其他部分。

记住无论如何都要把所有部分都放在上下文 map 上，包括外部系统，然后你会在文章和谈话中看到系统词的意思。