我目前正在设计一个新的企业系统。该系统的目的是跟踪，显示和通知员工与公司的客户交互（即事件）。使用事件源模式来保存所收集的所有客户交互/事件的分类帐似乎非常合适，因为我们所有其他域对象都是从事件流派生的。但是，我发现一篇文章说基于事件采购的整个系统是一种反模式。为什么会这样？
https://www.infoq.com/news/2016/04/event-sourcing-anti-pattern
答案 0 :(得分：8)
这篇文章确实总结了Greg在DDD Europe 2016上的“DDD，CQRS，事件采购十年”的演讲。
我个人不喜欢这个摘要的标题，因为这绝对不是格雷格谈话的重点。基本上，像往常一样，取决于。
当格雷格谈到系统时，他意味着整个事情。 DDD术语中的 thing 具有上下文映射，其中包含多个有界上下文。通常，在此上下文映射中，您可以标识子域，其中一个或多个子域可以另外标识为核心域。
当你拥有核心领域时 - 它将非常适合高级技术，这将是更传统的DDD战术模式，如聚合，或像“事件采购”这样的“发烧友”。实现确实需要基于上下文需求。
根据您的描述，您非常适合事件采购。但您可能会考虑系统的其他部分，例如客户/联系人管理和员工管理。这些细节应该来自某个地方。可能这些是CRUD候选人？因此，如果您的核心域是跟踪员工与客户之间的交互，某种类型的CRM，您可以决定使用事件采购和系统的其他部分使用不太先进的技术构建该部分
请记住，无论如何都要将所有部分放在上下文地图上，包括外部系统，然后您会看到 system 一词在文章和谈话中的含义。
答案 1 :(得分：5)
这篇文章引用了Greg Young的演讲。相关部分可见here.
Young解释说CRUD隐藏了“各种疯狂的用例”，并以纠正拼写错误为例。
他还指出，在事件源系统中，分析可能会更加昂贵。
一般而言，将不可变事件作为系统某一部分的真实来源，与读取模型分开，会带来成本，不应盲目采用。
Young表示“更像事件驱动的东西”将是顶级架构，而不是CQRS /事件源。