domain-driven-design - DDD 和 CQRS/ES 不是打破了 DDD 的持久性不可知性吗？

Question

DDD 中的域模型应该与持久性无关。

CQRS 要求我为我不想在读取模型中包含的所有内容触发事件。 (顺便说一下，将我的模型拆分为一个写模型和至少一个读模型)。

ES 要求我为所有改变状态的事件触发事件，并且我的聚合根必须自己处理事件。

这对我来说似乎不是很持久不可知。

那么如何将 DDD 和 CQRS/ES 结合起来，而不会对这种持久化技术对领域模型产生重大影响呢？

读取模型是否也在 DDD 域模型中？还是在它之外？

CQRS/ES 事件与 DDD 域事件相同吗？

编辑:

我从答案中得出的结论如下:

是的，对于 ORM，域模型对象的实现将与使用 ES 的实现不同。
问题是错误的方法。首先编写领域模型对象，然后决定如何持久化(更多事件如 => ES，更多数据如 => ORM，...)。

但是我怀疑如果您没有预先做出这个决定，您将永远能够使用 ES(没有对域对象进行大量添加/更改)，并且在没有预先决定的情况下使用 ORM 会导致非常痛苦。 :-)

Answer 1

命令

归根结底，CQRS 意味着您应该将读取与写入分开。

通常，命令到达系统并由某种函数处理，然后返回由该命令产生的零、一个或多个事件:

handle : cmd:Command -> Event list

现在您有一个事件列表。您所要做的就是将它们保存在某个地方。执行此操作的函数可能如下所示:

persist : evt:Event -> unit

然而，这种持久化功能纯粹是一个基础设施问题。客户端通常只会看到一个将 Command 作为输入并且不返回任何内容的函数:

attempt : cmd:Command -> unit

其余的( handle ，然后是 persist )是异步处理的，因此客户端永远不会看到这些函数。

查询

给定事件列表，您可以重放它们以将它们聚合成所需的结果。这样的函数本质上是这样的:

query : target:'a -> events:Event list -> Result

给定事件列表和要查找的目标(例如 ID)，这样的函数可以将事件折叠成结果。

执着无知

这是否会迫使您使用特定类型的持久性？

这些功能都不是根据任何特定的持久性技术定义的。你可以实现这样的系统

内存列表

Actor

事件商店

文件

Blob

数据库，甚至

等

从概念上讲，它确实迫使您从事件的角度考虑持久性，但这与 ORM 的方法没有什么不同，后者迫使您从实体和关系的角度考虑持久性。

这里的重点是将 CQRS+ES 架构与大多数实现细节分离是很容易的。这通常是持续的——足够无知。