领域事件的并发问题

Question

我有许多可以在我们的企业系统中调度的域事件。例如，如果有人创建或删除了地址。

我应该将整个实体作为事件的一部分传递，还是只传递 ID。消息通过服务总线发送并并行使用。

如果我只是发送 ID，那么如果同时发生删除，则该实体在消费者端可能不可用。我总是可以只使用一个活动标志并将其设置为 false 但是如果实体同时更新并且它改变了一些重要的东西怎么办。

我将如何处理这些案件？

Answer 1

我认为这是服务总线上的一个常见困境，我相信没有一个完美的解决方案。我假设这里的范围只是重要域对象更改状态时引发的事件（即不是事务命令，也不是读取/数据服务）

仅发送事件元数据而不是发送完整的参考消息（例如新的客户聚合根）的决定可能比仅与延迟相关的并发/版本控制问题具有更广泛的影响，例如两种方法的一些优缺点：

最小的Event 元数据：

• 负载更小（如果您审核总线上的所有消息，则特别有用）
• 非常适合标准信封
• 如果交付到未经授权的总线端点是相当安全的（系统获得的只是客户 XYZ 已更改的知识，而不是实际的详细信息）。

而完整的“聚合”根 Message 参考更新

• 如果大多数订阅者对完整的有效负载不感兴趣，这可能是矫枉过正。
• 潜在的安全问题 - 并非总线上的所有用户都有权获得完整的有效负载
• 但是对于补充 CQRS 读取存储缓存非常有用，因为端点一旦知道其数据已过期（数据已经提供），就无需返回事实源来获取数据。

所以我想最终决定将取决于您主要打算对 EDA 事件执行的操作（保持 CQRS 缓存更新、触发 BPM 工作流和监控 CEP 规则等）。您可能决定使用混合动力车，例如广泛广播事件数据，然后将完整消息路由到仅受信任的端点（事件元数据可能会从完整有效负载中投射出来，因此发起/真相源系统可以在每次状态更改后仅将一个消息有效负载发送到总线） .

要回答您的数据一致性问题，我相信您需要接受数据只会最终一致，并且延迟会导致整个企业的临时不一致。我相信这里最好的模式是为从原始真相源获得的每条消息添加一个哈希或时间戳，这需要添加到任何使用此版本数据作为假设的命令中。

然后，当命令处理系统处理命令时，它可以根据当前的“真实”版本检查这个哈希值（基于实际的业务线系统数据库，而不是读取存储缓存），并且需要失败哈希/时间戳不匹配时的命令 - 即乐观并发模式。