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

Question

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

Answer 1

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

传统。

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

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

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

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

事件溯源真的是一对思路

• 更改应该是我们 model 中的第一个 class 公民
• 我们的权威数据 model 应该是一系列变化（又名历史）

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

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

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

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

Answer 2

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

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

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