如何在事件溯源/事件中设计可否决事件

Question

让我们假设有一个简单的用例（java/microservice/event sourcing/eventuate）：

• 微服务 A 引入用户实体
• 微服务 B 引入了从我们的用户到某些外部用户存储（可能是 ldap 等）的同步

假设 B 出于某种技术原因无法更改用户名，但 A 本身允许更改用户名。

如何实现？在经典的巨石中，我们可能会围绕 java.beans.VetoableChangeSupport。在微服务中我遇到了麻烦。我的第一个想法是把它分成三个事件。

首先我们发布一个事件说“用户名将被更改”。每当微服务 B 不喜欢它时，第二个事件将是“取消用户名更改”。第三个事件将是“用户名更改成功”。

到目前为止，它会起作用。但是我们如何实现呢？我不喜欢有一个将所有微服务连接在一起的单体。我喜欢有一些“插件”的概念。只要我们不运行微服务 B，就没有人会否决，我们应该自动运行“用户名更改成功”。但是一旦我们运行微服务 B，我们就应该检查微服务 B 是否喜欢否决事件。

我们如何从“微服务 B 当前离线但很快会回来”中区分“微服务 B 未运行”？在第一种情况下，我们没有获得否决权。在第二种情况下，我们必须等待 B 再次回来检查未决的“用户名更改”事件。

Answer 1

如果您不希望依赖于微服务 B，那么我将只允许最初更改名称并将来自微服务 B 的拒绝视为最终一致性异常。

因此，在微服务 A 中，您尽可能确保更改不会导致 MS-B 同步到的任何问题。然后记录“用户名更改”事件。

如果 MS-B 没有运行，那么您就完成了，名称已更改。
如果 MS-B 正在 运行，并且在尝试同步更新的用户名时遇到问题，那么您将进入更正模式。这究竟意味着什么取决于很多事情（问题发生的可能性有多大，影响有多大等）。
您可能会让 MS-B 暂停并发送一封电子邮件，以便人工纠正这种情况。
或者您可能让 MS-B 发出反向更改（另一个“用户名已更改”或“名称更改恢复为：X” - 对您的域有意义的任何内容）。

如果您发出补偿事件，您将需要注意一些额外的例外情况...例如，如果User A 将其名称更改为User X，而User B 然后将其名称更改为User A。如果 MS-B 撤消了第一次改名，除非您还撤消了第二次改名，否则您最终会得到重复的名字。
（或者您可以在允许重新使用之前将旧用户名“锁定”一段时间。）