最终一致性是否与用户身份验证过程不兼容?

Mik*_*378 3 architecture authentication domain-driven-design web-applications cqrs

我在我的项目中练习DDD.

让我们假设有界背景IdentityAndAccessContextMeetingContext.

这两种情况都涉及以下术语:

  • IdentityAndAccessContext具有User类的概念.
  • MeetingContext具有Participant类的概念.(让我们忘记Creator这个例子).

Participant代表用户会议界上下文.

首先,User必须创建一个,导致a UserCreatedEvent.
然后,为了在这些有界上下文之间应用最终一致性,消息存储在IdentityAndAccessContext中,然后发送帮助事件监听器和消息队列(仍然在IAC上下文中)到MeetingContext,以便自动创建相应的Participant.

这听起来像是一个很好的DDD设计(IMO),但是我遇到了这个webapp工作流程的问题:

  • 用户通过注册表注册,然后重定向到主页.
  • 主页需要一些Participant值......这就是问题:
    最终一致性的过程可能在重定向到主页之前没有完成,导致"没有值".

如何处理这个案子?
让用户在一致性通知之前等待?糟糕的UX没有?在同一个事务中
插入ParticipantUser?......违反有界的背景概念,不是吗?

Ebe*_*oux 6

我建议的是设计您的UI时要考虑到最终的一致性.假设你欠你的ISP 10美元.您进入您的网上银行网站并执行电子转帐.您登录到您的ISP帐户页面,但您的付款没有反映出来.在这种情况下,期待这笔钱立即反映听起来几乎是愚蠢的.预期最终的一致性,您可能会点击"刷新"按钮,直到资金反映或只是等待一两天的交易反映,因为这是期望.

我不认为您应该尝试使用消息传递来创建交互式系统,因为它本质上是异步的,并且没有真正的确定性结果.但是,您可以在"来源"有界上下文中跟踪注册过程,因此,知道该消息已经发送并在参与者页面上报告; 类似于:'您的参与请求正在进行中'.

然后使用某种形式的轮询或基于服务器的推送技术,您可以在参与者对象准备好后更新参与页面.

这可能听起来过于简单,但我仍然认为人们的目标应该是考虑到不确定性.

希望有所帮助.