事件采购：更详细的分裂事件

Question

在我的域中进行用户注册过程时会发生以下几种操作：用户创建（使用电子邮件/密码或链接的社交网络帐户），用户登录已完成。

我有（看）两个选项如何注册事件：

• 一个UserRegistred事件（包含所有信息，密码哈希值，外部社交帐户）
• 多个活动UserCreated，UserPasswordSet，UserExternalAccountLinked，UserLoggedIn

第二个选项（UserPasswordSet，UserExternalAccountLinked，UserLoggedIn）中的事件可能会在执行相应操作时自行显示。

我理解问题和选项可能是主观的，但我想听听有经验的ES / DDD用户对此问题的看法。

Answer 1

我并不声称自己很有经验，但我认为输出多个事件更简单，而不是复杂的简单事件。

专业人士：

• 简单性 - 预测（包括聚合本身）和其他事件处理程序不需要了解复杂的UserRegistered事件以及细粒度事件
• 减少事件架构的流失 - 例如如果您更改身份验证事件的详细信息，则需要更改的事件类型更少（因为没有要更改的UserRegistered事件）
• 清晰度 - 事件更好地捕获用户注册中涉及的状态更改序列

我能想到一个小小的骗局：

• 非原子注册。它可能的预测可以处理单个用户注册的事件，并在客户端可以立即查询的状态下原子地创建读取模型。如果您有多个事件，则读取模型可能会逐个处理它们，这意味着用户可能暂时处于半注册状态，您可能不想在客户端中处理。
  • 这可以通过让您的读取投影消耗所有可用事件并在单个事务中进行更新来避免，这样事件序列只会导致单个事务提交，因此您永远不会看到半注册用户。这在任何情况下都更有效，但可能不那么简单，具体取决于您的读取存储。
  • 或者，您可以在查询服务时自动过滤掉半注册用户