我开始从 DDD 的角度学习 EventSourcing。关于 EventSourcing 的一项声明是,它允许通过重播事件来重播应用程序的状态,甚至可以将应用程序置于之前的状态(过去的状态)。
我正在意识到它增加的复杂性以及它相对于其他解决方案的优势。我真正关心的是事件的生成发生在哪里。前端还是后端?
我会用一个例子来解释它。
想象一下,我的应用程序由前端和后端组成,与用户有关。用户表示可能如下(我将使用 JSON 进行表示,尽管问题不是特定于格式或语言):
{
id: int,
name: string,
age: int,
description: string
}
第一个问题:
假设我从前端创建一个用户。我的服务器收到以下信息:
{
id: 1,
name: "aName",
age: 20,
description: "aDescription"
}
是否应该发出以下事件? CreatedEvent、NameChangedEvent、AgeChangedEvent、DescriptionChangedEvent
在这种情况下,前端生成的事件(只有一个)与后端生成的事件(四个)不同。
或者应该发出具有所有属性的 CreatedEvent?在这种情况下,后端的事件类似于前端的事件(只有一个)
执行更新时也会出现类似的问题。如果我从前端一次更改多个属性,我应该在后端创建一个包含所有这些更改的事件,还是应该将这些更改拆分为多个事件?如果我必须将这些更改拆分为多个事件,我将必须检查实体(用户)的当前状态以检查属性是否已更改。
最佳答案
你还在思考CRUD
。在CQRS
中,您不设置属性,而是执行命令
。这些命令
对您的域模型有意义;它们被发送到聚合,如果不变量成立,聚合将验证并执行它们;如果没有,他们就会被拒绝。
I'm realising the complexity it adds and the benefits it has over other solutions. What I am really concerned about is where the generation of events occurs. Front-end or back-end?
事件由聚合生成,并且聚合可能在后端执行。前端只能创建发送到后端的命令。
Should the following events be emitted? CreatedEvent, NameChangedEvent, AgeChangedEvent, DescriptionChangedEvent
应发出哪些事件取决于您的不变量。在您的具体情况下,业务规则允许用户
出生时没有姓名
、年龄
或描述
?如果没有,那么您必须在 CreateUserCommand
中放入所有必填字段以及可能的可选字段,并发出完整的 UserWasCreated(id, username,age, description)
。但并不禁止发出多个事件,只要它们以类似事务的方式持久化(不要求使用事务,要求持久化是原子的:所有事件都是持续或无)。您应该发出一个大事件还是四个?这取决于这些事件的监听者感觉如何,因为它与聚合无关:聚合将接收它发出的内容,并且足以重建其内部状态。
生成事件的粒度可能取决于您是否允许像 ChangeUserName
这样的粒度命令;如果您允许这样的命令,那么该命令将发出 UserNameChanged
事件。
关于事件溯源。事件粒度在哪里生成?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42766430/