为什么 DDD 用于 CQRS 和事件溯源应用程序？

Question

我刚开始使用 CQRS，即事件溯源。在研究许多框架时，我意识到大多数框架假设我们的应用程序是基于 DDD 原则建模的一件事。我不确定，但谁能向我解释 DDD、CQRS 和事件溯源如何相互关联，以及为什么通常需要 DDD 来实现 CQRS 和事件溯源模式？

Answer 1

为什么通常需要 DDD 来实现 CQRS 和事件溯源模式？

传统。

在更名为“CQRS”之前，相同的创意集合带有“分布式领域驱动设计”的标签。 Greg Young 早期的演讲是经验报告，描述了他在设计算法交易系统时如何适应 Evans 发表的想法。

实际上，这意味着发现 CQRS 和事件溯源的大多数观众已经相信领域驱动设计是一个好主意。

不过，它们是不同的想法；即使您不进行事件溯源，CQRS 模式也可能很有用。

谁能向我解释一下 DDD、CQRS 和事件溯源是如何相互关联的

事件溯源真的是一对思路

• 更改应该是我们模型中的一等公民
• 我们的权威数据模型应该是一系列变化（又名历史）

这种数据模型非常适合写入（只需在列表末尾附加一个新更改），并且具有编辑是非破坏性的额外好处；添加到系统中的所有信息仍然存在，因此您可以轻松地通过时光机回溯以了解发生某些变化之前的情况。

但历史记录suck 用于低延迟查询。因此：缓存 - 我们将预先计算一些问题的答案，并将它们放入属性包中。

现在我们有两个模型：历史和缓存。什么是 CQRS？

CQRS 只是创建两个对象，而以前只有一个对象 -- Greg Young 2010

Answer 2

我认为这不仅仅是传统。在设计将事件用作状态转换的系统时，最有用的方法是摆脱 CRUD 样式的事件（SomethingCreated、SomethingUpdated 等），而是对实际行为进行建模。这就是事件溯源非常接近 DDD 的基本思想的地方 - 丰富的领域模型，用通用语言表达。

另外，当我们设计一个事件源系统时，我们会花一些精力来定义流边界，所以我们不会得到大事务，我们没有多流事务，平均流长度是上限等等。所有这些问题都与 DDD 的战术聚合模式非常吻合。

当人们只是将事件推送到 Kafka 主题并将它们投影到某些数据库时，他们本质上不是在进行事件溯源，而是在实现一个事件驱动的系统。