CQRS/ events :应该共享事件(类型)吗？

Question

事件是否应该被分享？我正在试验CQRS和事件源，我想知道事件(类型)是否应该在服务之间共享/定义。

案件：

传入一个请求，并将一个新的createUser命令推入“命令”事件日志。服务A(业务逻辑)获取此命令并生成新用户的数据。创建新用户后，它会将新数据推入事件名为newUser的“events”事件日志中。服务B(投影仪)注意到新事件并开始处理它。

这是我的问题。我们是否应该为每个事件类型(在本例中为newUser)定义需要运行的逻辑，以更新物化视图？在下面的示例中，我们有2种类型的事件，对于每一个事件，我们都定义了需要发生的操作。在这种情况下，是在logics服务和投影仪服务中定义的事件类型。

# <- onEvent
switch event.type
  case "newUser"
  putUsers(firstName=data.firstName, lastName=data.lastName) # put this data in the database

  case "updateUserFirstName"
  updateUsers(where id = 1, firstName=data.firstName)

或者在这种情况下定义需要预先设置的操作类型是个好主意吗？在这种情况下，事件类型不是共享的，投影仪服务可以处理未知/新事件，而不需要任何修改。

# <- onEvent
switch event.operation
  case "create"
  putUser(...)

  case "update"
  updateUser(...) # update only the data defined in the event

备选方案2是可行的选择吗？还是我在选择这个策略时会遇到问题？

Answer 1

事件反映了已经发生的事情。它们通常用过去式命名-- userCreated。

一般事件(或每个实体一种事件类型)有许多缺点：

• 为事件类型找到合适的过去式名称变得更加困难。
• 你失去了一些表现力，因为仅仅看一下事件类型，整个领域的意义就不再明显了。
• 不可能以细粒度、流线型的方式订阅事件，因为您需要“打开信封”以找出您正在处理的特定事件。
• 您与域专家讨论的事件之间的差异(例如在事件风暴会议期间)和它们在类型、消息中的编码方式之间的差异。

我不推荐它，除非是在一个非常自由的形式/动态系统中，在这种系统中，实体是事先不知道的。

Answer 2

我建议使用事件类型来确定哪些类型的业务逻辑/规则将使用该事件。

正如@guillaume31 31所提到的，用过去式来命名你的事件。但是如果你想为未来做计划，你也应该对你的事件类型进行版本化。例如，您可以将事件类型命名为"userCreated_v1“或"userFirstNameChanged_v1”。这使您能够在将来更改事件消息的结构，并轻松地将新的业务逻辑/规则与新事件关联起来。