CQRS跟踪用户更改

Question

我们目前正在研究构建我们(Web)应用程序的新方法，其中一种开始考虑的方法是CQRS。我们对此仍有几个问题：

如果我正确理解，这可能意味着有两个或更多的领域模型，一个核心领域模型和一个读取模型的webapp。

这个核心域模型不是由webapp直接写入的，而是由另一个服务编写的。我们正在考虑使用NServiceBus来创建一个发布者/处理程序，以便webapp能够发布用户所做的更改。然后，订阅者将处理消息并更新核心域模型和读取模型。

我们想要达到的目标：

用户A创建10个新对象，例如书籍。

消息订阅者需要处理大量消息，因此更新域模型需要几分钟时间。

当用户A刷新页面时，他应该会看到他刚刚创建的10本书。

当用户B刷新页面时，他实际上并不需要看到这些项目。

你最好把这10个新东西存放在哪里？

将这些数据与读取模型中的“旧”数据合并的最佳方法是什么？

假设用户B也需要查看这些新项，那么存储这些数据的最佳方法是什么？

什么是处理两个不同用户同时添加同一本书的最佳方法？(除书的描述外，所有数据都相同)。它仍然是同一本书：)

您如何处理对这10个对象中的一个的更新，这些对象尚未写入核心域模型，因此没有唯一的id？

Answer 1

在我看来， CQRS有很多不同的方面需要考虑。我从中学到的核心是用户操作(命令、->、写入模型)和显示信息(查询<- read模型)的分离。然后，我可以根据应用程序的需求，挑选和选择其他自然适合这种分离的体系结构模式。请记住，CQRS并不意味着它是一个顶级架构，您应该从中挑选和选择，并且只在适当的时候使用。

我从你的问题中得到的印象是，你的研究没有取得多大进展，所以我推荐以下几点：初始CQRS文档、Rinat Abdullin的博客、乔纳森·奥利弗斯的博客(读一些旧的东西)和Rinat的CQRS指南(尽管我还没有阅读过这个网站)。

我保证读过CQRS文档之后你就能自己回答你的问题了。

也许，如果您告诉我们您希望使用的模式/技术，我可以提供一个更完整的答案。但要开始你的第一个问题，它是相当直截了当的：

你最好把这10个新东西存放在哪里？

答案是，从逻辑上讲，您可以将部分数据存储在读写模型中；根据您选择的技术和实现(例如server数据库与键值无sql解决方案)，可以在物理上将其存储在同一个数据存储区或不同的数据存储区。

如果您选择使用事件源，那么您就会将事件存储在写模型中。读取模型将存储非规范化、精心编制的数据，这样您的屏幕就可以由读取模型的数据组成。但这与我所看到的模式是一致的；您的读取模型只需存储与查询服务标准化的数据，就可以对现实数据库执行实际的sql查询。

编辑以下注释

我目前正在使用的系统不使用消息传递，尽管它确实使用了事件。所有的东西都是in.因此，命令被处理；事件在同一工作单元内被引发和处理。基本上，在适当的事件处理程序都完成之前，命令处理程序不会完成。

当读取模型有更密集/更复杂的更新时，我们仍然在考虑out-of-process事件处理程序。但是在这个阶段不需要它，它使事情变得简单。

整个最终的一致性只是模式带来的东西。对于“其他”用户来说，这不会是一个问题，但是对于刚刚提交并刷新页面的用户来说，我可以看到，如果没有看到他们刚刚提交的更新，这会让我感到困惑。就我个人而言，我不喜欢假装更新的想法，因为这就像加倍努力。相反，我更喜欢重定向到确认页面的选项，这为应用程序处理消息提供了更多的时间。

我个人想进一步探讨的是跟踪已提交的命令以及相关的进程外事件处理程序。用户刷新尚未完成邮件的页面时，可能会收到不完整消息的通知。消息处理完成后，可以将通知“推送”到客户端。我会使这些通知微妙，以免分散用户的注意力，或变得烦人和妨碍。