CQR可以用于StackOverflow这样的站点吗?

实际上,您所说的是“最终一致性”,这与CQRS经常同时讨论,但您可以独立地使用这两种技术。

最简单的方法是立即更新UI正在使用的模型,并使用它将问题显示给用户以供进一步操作。为了让其他用户看到更新而要做的各种工作可以在不阻塞UI的情况下继续进行。要做到这一点,您需要验证您的命令,这样在发出命令之前几乎可以肯定会成功(如果命令在执行过程中失败,那么您需要处理这种情况,例如,合并某种对UI模型的回调)。

让我们看看这两个问题。。。

我投的票立即反映出来。在CQRS中,我可以想象这些命令/事件最终通过事件总线移动到读存储。但他马上给了我信息。

是不是马上给你?让我们试试另一个例子,Facebook。当你点击喜欢的东西时,它会立即出现在你的喜欢中吗?像竖起大拇指这样的UI技巧会让你感觉像是这样。另一个例子,亚马逊。当您单击“添加到购物车”时,它是否立即进入您的购物车?像“添加到购物车”或“竖起大拇指”这样的视觉表现让你作为一个用户感觉它已经完成了。

有许多这样的技巧可以让最终一致的系统感觉像一个完全一致的系统。

当你问一个问题时,你可以在UI中“伪造”数据。它看起来像是立即更新给用户(你),但它将需要一段时间之前,其他用户将看到你的问题。你需要做同样的事情来处理投票。

如果您需要即时反馈,您可以考虑其他解决方案。但是,在CQRS解决方案中,您可以使用一些技巧来提供即时反馈。例如,如果需要验证用户名是否为uniqe,可以查询read数据库以确定该用户名是否存在。如果没有,你可以用它。但是,如果其他用户同时选择了相同的用户名,您将在命令端遇到冲突。您需要在域模型中处理这个问题,例如,给用户一个生成的用户名并通过电子邮件发送给他。他以后可以换成别的东西。

客户端命令队列/历史记录可能是帮助处理后续事件依赖于最终失败的挂起提交的情况的一种方法。换句话说,依赖于挂起提交的任何内容都可以是历史记录的一部分,可以在对失败的挂起提交进行更正时进行汇总、保存、展开并重新应用于已更改并重新提交的挂起事件,并且一旦通知挂起事件成功提交,所有后续的客户端历史记录都将开始展开,提交队列中的下一个项目,并将其标记为当前挂起的事件。