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