使用CQRS和EventStore创建并发

Question

基线信息： 我正在使用外部OAuth提供程序进行登录。如果用户登录到外部OAuth，则可以进入我的系统。但是，我的系统中可能尚不存在此用户。这不是一个真正的技术问题，但我正在使用JOliver EventStore来实现它的价值。

逻辑：

1. 我没有为新用户提供指导。我只是有一个电子邮件地址。
2. 如果用户发送电子邮件，我会在发送命令之前检查我的阅读模型 存在，我发出一个带有ID的登录命令，如果不是，我发出一个 具有生成的ID的CreateUser命令。我的问题是新用户的情况。
3. 使用新ID在事件存储中进行保存。

问题： 假设在读取模型更新之前以某种方式发布了两个创建命令，这是由于浏览器刷新或在实现与读取模型的一致性之前发生的一些其他异常。那没关系，这不是我的问题。

发生了什么： 因为新ID是Guid梳子，所以事件存储器不可能知道这两个CreateUser命令代表同一个用户。当他们到达读取模型时，读取模型将知道（因为他们具有相同的电子邮件）并且可以合并两个记录或采取一些其他补偿操作。但是现在我的阅读模型与事件存储不同步，事件存储仍然认为它们是两个独立的实体。

也许无所谓因为：

1. 重播事件将对读取模型产生相同的影响 所以应该没问题。
2. 因为两个命令都是重复的“创建”命令，所以它们应该包含相同的信息，所以它不像我在事件存储中丢失任何东西。

有人可以说明他们如何处理类似问题吗？如果需要进行某些补偿操作，那么当读取模型服务意识到它有重复的条目时会发出某种补偿命令吗？有没有更简单的方法我不考虑？

谢谢！

Answer 1

你非常接近我认为合适的解决方案。如果我可以总结的话，这个场景有点像这样：

• 执行OAuth-entication。
• 使用阅读模型根据电子邮件地址决定定期访问者和新访问者。
• 如果是新访问者，请发送一个RegisterNewVisitor命令消息，该消息将被处理并存储在eventstore中。
• 假设存在一些并发性，对于相同的电子邮件地址，会导致两条RegisterNewVisitor消息，每条消息包含系统认为是与电子邮件地址关联的密钥。这些键（guid）是不同的。
• 在读取模型中检测此重复键问题，并将读取的模型记录合并到一个记录中。

现在，不要将读取模型中的记录合并，为什么不向您的域模型发送ResolveDuplicateVisitorEmailAddress {Key1，Key2}，将其留给域模型（要采取的业务决策的编码形式）来解决这个问题。您甚至可以使用专用的读取模型来处理这类问题，另一个读取模型只会获得一种DuplicateVisitorEmailAddressResolved事件，并将其投影到正确的记录中。

警告语：您已经提出了技术问题，我给了您一个技术上可行的解决方案。一般情况下，我不会应用这种技术，除非我有一些业务指标值得投资（用户首次同时登录的频率是多少 - 也许以这种方式解决它只是忽略根本原因的一种方式（flakey OAuth，没有注册新访客流程等））。这个问题还有其他技术解决方案，但我想给你一个最接近你现有的解决方案。它们的范围从顺序注册新访问者到保留读取模型中尚未访问的访问者的内存中投影。