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

Question

我目前正在设计一个新的企业系统.该系统的目的是跟踪,显示和通知员工与公司的客户交互(即事件).使用事件源模式来保存所收集的所有客户交互/事件的分类帐似乎非常合适,因为我们所有其他域对象都是从事件流派生的.但是,我发现一篇文章说基于事件采购的整个系统是一种反模式.为什么会这样？

Answer 1

这篇文章确实总结了Greg在DDD Europe 2016上的"DDD,CQRS,事件采购十年"的演讲.

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

当格雷格谈到这个系统时,他意味着整个事情.在DDD术语中,这个东西有一个上下文映射,有多个有界上下文.通常,在此上下文映射中,您可以标识子域,其中一个或多个可以另外标识为核心域.

如果你拥有自己的核心领域 - 将会很好地适应高级技术,这将是更传统的DDD战术模式,如聚合,或像"事件采购"这样的"发烧友".实现确实需要基于上下文需求.

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

请记住,无论如何将所有部分放在上下文地图上,包括外部系统,然后您将看到系统词在文章和谈话中的含义.

Answer 2

文章引用了格雷格·杨（Greg Young）的讲话。相关部分在此处可见。

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

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

通常，将不可更改的事件作为系统给定部分的真相源，并与读取的模型分离会带来成本，因此不应盲目采用。

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