让我们假设有一个简单的用例（java / microservice / event sourcing / eventuate）：
我们假设B由于某些技术原因无法更改用户名，但A本身允许更改用户名。
怎么实现这个？在经典的巨石中，我们可以围绕java.beans.VetoableChangeSupport构建一些东西。在微服务中我遇到了麻烦。我的第一个想法是把它分成三个事件。
首先，我们发布一个事件，说“用户名将被更改”。当微服务B不喜欢它时，第二个事件将是“用户名更改被取消”。第三个事件将是“用户名更改成功”。
到目前为止它会起作用。但是我们如何实现呢？我不喜欢将所有微服务连接在一起的整体结构。我喜欢有一些“插件”概念。只要我们不运行微服务B，就没有人做过否决权，我们自动应该运行“用户名变更成功”。但是一旦我们运行微服务B，我们应该检查微服务B是否喜欢否决该事件。
我们如何将“微服务B未运行”从“微服务B目前处于脱机状态但很快就会恢复”？在第一种情况下，我们没有获得否决权。在第二种情况下，我们必须等待B再次返回以检查待处理的“用户名已更改”事件。
如果您不希望依赖于微服务B，那么我最初只允许更改名称，并将微服务B中的拒绝视为最终的一致性异常。
因此，在微服务A中，您尽可能地确保更改不会导致MS-B可能同步的问题。然后，您记录“用户名已更改”事件。
如果MS-B没有运行，那么你在这里完成，名称改变了。 如果MS-B正在运行，并且在尝试同步更新的用户名时遇到问题，那么您将进入更正模式。究竟是什么意味着取决于许多事情（问题发生的可能性，影响是什么等）。 您可能暂停MS-B并发送电子邮件，以便人员可以纠正这种情况。 或者你可能让MS-B发出逆转变化（另一个“用户名已更改”或“名称更改还原为：X” - 对您的域名有意义）。
如果您发布补偿事件，您还需要注意一些额外的例外情况......例如，如果User A将其名称更改为User X，则User B会将其名称更改为User A。如果MS-B反转了第一个名称更改，您将使用重复的名称，除非您还反转第二个名称更改。
（或者也许你可以在允许重新使用之前将旧用户名“锁定”一段时间。）