我在我的项目中实践 DDD。
让我们假设 boundedcontext IdentityAndAccessContext 和 MeetingContext。
两种上下文都涉及以下术语:
- IdentityAndAccessContext 具有
User类的概念。 - MeetingContext 具有
Participant类的概念。 (让我们忘记Creator的例子)。
Participant 代表Meeting 限界上下文中的用户。
首先，必须创建一个User，导致一个UserCreatedEvent。
然后，为了在这些限界上下文之间应用最终一致性，将消息存储在 IdentityAndAccessContext 中，然后将帮助发送到事件监听器和消息队列(仍在 IAC 上下文中)到 MeetingContext，在命令自动创建相应的Participant。
这听起来像是一个很好的 DDD 设计(IMO)，但是我遇到了这个网络应用程序工作流程的问题:
- 用户正在通过注册表进行注册，他被重定向到主页。
- 主页需要一些
Participant值...这就是问题所在:
最终一致性过程可能在重定向到主页之前未完成，导致“无值”。
如何处理这种情况？
让用户在一致性通知之前等待？糟糕的用户体验不是吗？
在 User 的同一事务中插入 Participant 值？ ...违反限界上下文概念，不是吗？
最佳答案
我建议在设计 UI 时考虑到最终的一致性。假设您欠 ISP 10 美元。您进入网上银行网站并执行 EFT。您登录到您的 ISP 帐户页面，但您的付款没有反射(reflect)。在这种情况下，期望钱立即反射(reflect)出来听起来几乎是愚蠢的。最终的一致性是预期的，您可能会点击“刷新”按钮直到资金反射(reflect)出来，或者只是等待一两天让交易反射(reflect)出来，因为这是预期的。
我认为您不应该尝试使用消息传递创建交互式系统，因为它本质上是异步的，没有真正的确定性结果 w.r.t.定时。但是，您可以在“源”限界上下文中跟踪注册过程，因此知道消息已发送并在参与者页面上报告；类似于:“您的参与请求正在处理中”。
然后使用某种形式的轮询或基于服务器的推送技术，您可以在参与者对象准备就绪后更新参与页面。
这听起来可能过于简单，但我仍然认为人们应该在设计时考虑到不确定性。
希望对您有所帮助。
关于authentication - 最终一致性是否与用户身份验证过程不兼容？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23061462/