事件溯源。事件粒度在哪里生成？

Question

我开始从 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？在这种情况下，后端的事件类似于前端的事件(只有一个)

执行更新时也会出现类似的问题。如果我从前端一次更改多个属性，我应该在后端创建一个包含所有这些更改的事件，还是应该将这些更改拆分为多个事件？如果我必须将这些更改拆分为多个事件，我将必须检查实体(用户)的当前状态以检查属性是否已更改。

Answer 1

你还在思考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 事件。