我们的项目是使用 DDD 开发的。我们决定将用户身份转移到单个微服务中，该微服务将用于检查用户身份、颁发和验证令牌。
现在，由于帐户和用户位于解决处理用户和帐户详细信息问题的不同微服务中，我们遇到了一个称为最终一致性的挑战。
我们的问题是，我们是否应该首先在帐户和用户微服务中创建帐户/用户，然后将事件发布到用户身份微服务，反之亦然。
在第一种情况下，我们将立即获得帐户和用户的基本信息，但由于最终的一致性延迟，无法提供令牌，因此没有用户能够登录。
在第二种情况下，用户可以登录，但是当他登录到他的帐户时，由于最终的一致性延迟，将没有可用的帐户信息。对于这种情况，当满足最终一致性时发送确认邮件的解决方法，因此用户可以确认注册和登录。
我想听听反馈，哪种情况更有意义，还有什么我现在看不到的问题吗？
如果你有一把锤子，那么一切看起来都像钉子。看起来你太努力地将宏大的想法应用到一个不值得的问题上。
当使用 DDD 解决问题时，考虑战略 DDD 是至关重要的，即设计部分。限界上下文是特定语言存在的地方，并表现为与特定业务能力相关联的实现。
现在，您的工作是查看每个 BC 以判断哪种架构适合该环境。我应该说不应该，整个系统不必遵循相同的实现。您真的需要微服务来创建帐户\登录吗？听起来您可以摆脱类似 CRUD 的实现，消除您引入的任何最终一致性问题。
保持简单，先生。
不需要最终的一致性延迟。regiatrationCompleted 事件应该只在所有部分都完成后发生。此事件是您的界面将响应、触发欢迎电子邮件和更多类似操作的内容。
由于不同的微服务可以并行处理事件，因此引发此 registrationCompleted 事件的时间应该很短。
在没有帐户信息的情况下登录是所有选项中最糟糕的，因为您可能会遇到安全问题（例如具有某些权限或被锁定的帐户）。
另请注意，微服务只能尽可能小，不能更小。你不能合理地处理一个拆分案例，然后你把它做得太小了。