CQRS-最终一致性
我需要按照 CQRS 模式实现以下场景：
- 用户登录
- 用户输入一些保险详细信息
- 用户要求应用决策
- 用户查看决策结果
这看起来相当简单，但是我的问题在步骤 3 和 4 之间，在步骤 3 中，我发送一个 ApplyForDecision 命令，该命令将从承保服务中获取决策，然后将包含该决策结果的事件发送到总线以进行读取存储以便稍后使用它并使用决策结果更新视图表。
问题出在 UI 上，如何让用户知道正在应用决策，因为在 CQRS 中，读取模型不会“立即”更新，如何让 UI 显示决策正在进行中并将“很快” ' 到达？
我还需要让用户能够注销并重新登录，因为该决定可能尚未应用，如何使 UI 显示“待定决定屏幕”？
I have the following scenario which I need to implement following the CQRS pattern:
- a user logs in
- the user enters some insurance details
- the user ask for a decision to be applied
- the user views the result of the decision
This seems fairly straightforward, however my problem is between step 3 and 4, on step 3 I send a ApplyForDecision command which will get a decision from a underwriting service, an event with the result of that decision is then sent to the BUS for the read store to later consume it and update the view tables with the decision result.
The problem is on the UI, how do I let the user know that the decision is being applied, since in CQRS the read model is not updated 'straightaway' how do I make the UI show that a decision is in progress and will 'soon' arrive?
I also need to give the user the ability to log out and log back in, since the decision may not have been applied yet, how do I make the UI show the 'pending decision screen'?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
恕我直言，解决方案是让您的命令发出“ApplyForDecisionRequested”和“ApplyForDecisionHandled”事件，并相应地更新您的读取模型。
IMHO the solution would be to let your command emit an "ApplyForDecisionRequested" and an "ApplyForDecisionHandled" event, and update your read model accordingly.
答案是立即引发一个事件，指示已申请决策，更新读取数据库并立即重定向到待定决策屏幕，无论当时读取数据库是否已更新。静态文本“待决定，我们将联系您”或类似的内容。他们可以刷新或稍后返回，并且很可能会获得真实数据。然后，当决定做出后，您将有一个 DecisionMade 事件并相应地更新读取的数据库、发送电子邮件（无论何种情况）。
这就是您必须在 CQRS 中处理的最终一致性的权衡。通常，当我对表单上的域对象属性进行更改时，我会在后端执行其杂务时在用户收到的即时反馈中伪造它。是的，有点难看，但用户不知道。
The answer is to immediately raise an event indicating the decision has been applied for, update the read DB and redirect straight away to your pending decision screen whether or not the read DB has been updated by that time. Static text 'Pending decision you will be contacted' or something along those lines. They can refresh or come back later and more than likely will get the real data. Then when the decision has been decided, you have a DecisionMade event and update the read DB, send emails out, whatever the case, accordingly.
That's the trade off with eventual consistency you have to deal with in CQRS. Often when I've made changes to domain object properties on a form, I fake it in the immediate feedback the user gets while the back end does its chores. Yes, a little ugly but the users don't know that.