为什么整个系统事件采购是一种反模式？

Question

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

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

Answer 1

这篇文章确实总结了格雷格在2016年DDD欧洲论坛上的演讲“十年DDD，CQRS，Event Sourcing”。

我个人不喜欢这个摘要的标题，因为这绝对不是格雷格讲话的重点。基本上，和往常一样，这取决于。

当格雷格谈到系统时，他指的是整个事情。这个东西，用DDD术语来说，有一个上下文映射，有多个有限制的上下文。通常，在此上下文映射中，您可以识别子域，其中一个或多个域还可以标识为核心域。

当你拥有你的核心领域时执行工作确实需要根据具体情况的需要。

从你所描述的情况来看，你很适合进行活动采购。但是，您可能会想到系统的其他部分，例如，客户/联系人管理和员工管理。这些细节应该来自某个地方。这些人可能是废物候选人吗？因此，如果您在本例中的核心域是跟踪员工和客户之间的交互，某种类型的CRM，您可以决定使用事件源和系统的其他部分使用不太先进的技术来构建该部分。

记住，无论如何，将所有部分放在上下文地图上，包括外部系统，那么您将在文章和谈话中看到系统单词的意思。

Answer 2

这篇文章引用了格雷格·杨的讲话。相关部分是可查看的这里。

杨解释说，CRUD隐藏了“各种疯狂的用例”，并以纠正排字为例。

他还指出，在事件来源的系统中，分析可能会更昂贵。

一般说来，把不可变的事件作为系统某一部分的真理来源，与阅读模型分离，是有代价的，不应盲目采用。

Young建议，“更像事件驱动的东西”将是一个顶级架构，而不是CQRS/事件源。