整个系统事件为什么会出现反模式？

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 /事件采购。