【问题标题】:CQRS - Eventual ConsistencyCQRS - 最终一致性
【发布时间】:2010-08-05 11:39:06
【问题描述】:

我需要按照 CQRS 模式实现以下场景:

  1. 用户登录
  2. 用户输入一些保险细节
  3. 用户要求应用决定
  4. 用户查看决策结果

这看起来相当简单,但是我的问题在第 3 步和第 4 步之间,在第 3 步中,我发送了一个 ApplyForDecision 命令,该命令将从承保服务处获得决定,然后将带有该决定结果的事件发送到BUS 供读取存储稍后使用它并使用决策结果更新视图表。

问题出在 UI 上,我如何让用户知道正在应用决策,因为在 CQRS 中,读取模型没有“立即”更新我如何让 UI 显示决策正在进行中以及“很快”会到来吗?

我还需要让用户能够退出并重新登录,因为该决定可能尚未应用,如何让 UI 显示“待决决定屏幕”?

【问题讨论】:

  • UI 是 Web 客户端还是智能客户端?
  • 状态是否发生了任何变化?我的意思是,这个决策应用程序是某种需要确认的计算形式吗?如果是这样,这对系统中的“其他人”是否可见?这个场景如何高度协作?

标签: cqrs eventual-consistency


【解决方案1】:

答案是立即引发一个事件,表明该决定已被申请,更新读取数据库并立即重定向到您的待决决定屏幕,无论此时读取数据库是否已更新。静态文本“待决定将与您联系”或类似的内容。他们可以刷新或稍后返回,并且很可能会获得真实数据。然后,当决​​定做出决定时,您有一个 DecisionMade 事件并相应地更新读取的数据库、发送电子邮件,无论如何。

这是您必须在 CQRS 中处理的最终一致性的权衡。通常,当我对表单上的域对象属性进行更改时,我会在后端做家务时在用户获得的即时反馈中伪造它。是的,有点丑,但用户不知道。

【讨论】:

  • 很好的答案,尤其是关于用户不知道的问题。这是关键,确保用户不会注意到。例如,您可以在浏览器或服务器缓存中存储该项目已更新。当您访问数据的 readmodel 并在您的缓存中您注意到数据尚未更新时,您自己这样做,但仅针对该用户。 SignalR 也非常适合尽快更新其他客户端。
【解决方案2】:

恕我直言,解决方案是让您的命令发出“ApplyForDecisionRequested”和“ApplyForDecisionHandled”事件,并相应地更新您的读取模型。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2018-06-25
    • 1970-01-01
    • 2018-12-20
    • 2015-06-05
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多