RPM*_*984 1 domain-driven-design read-write cqrs
我读过一些与此相关的帖子，但我仍然不太明白它是如何工作的。
举例来说，我正在构建一个像 Stack Overflow 这样的网站，有两个页面 => 一个列出所有问题，另一个页面供您提出/编辑问题。一个简单的、基于 CRUD 的 Web 应用程序。
如果我使用 CQRS，我将拥有一个单独的读/写系统、单独的数据库等......太棒了。
现在，我的问题是如何更新读取状态（毕竟在它自己的数据库中）。
我认为流程是这样的：
WebApp => User submits question
WebApp => System raises 'Write' event
WriteSystem => 'Write' event is picked up and saves to 'WriteDb'
WriteSystem => 'UpdateState' event raised
ReadSystem => 'UpdateState' event is picked up
ReadSystem => System updates it's own state ('ReadDb')
WebApp => Index page reads data from 'Read' system
假设这是正确的，这与从同一数据库读取/写入的 CRUD 系统有何显着不同？抛开 CQRS 的优点（例如单独的读/写系统扩展、重建状态、域边界分离等），从持久性的角度来看，可以解决哪些问题？避免了锁争用？
我可以通过使用队列在多线程 Web 应用程序中实现单线程保存，或者简单地在读/写数据库之间复制数据来实现类似的优势，不是吗？
基本上，我只是想从务实的角度了解我是否正在构建基于 CRUD 的 Web 应用程序，为什么我会关心 CQRS。
谢谢！
\n\n\n假设这是正确的，这与从同一数据库读取/写入的 CRUD 系统有何显着不同？抛开 CQRS 的优点（例如单独的读/写系统扩展、重建状态、域边界分离等），从持久性的角度来看，可以解决哪些问题？避免了锁争用？
\n
这里的问题是：
\n\n\n\n\n“抛开CQRS优势\xe2\x80\xa6”
\n
如果你去掉它的优点，就很难争论它解决了什么问题;-)
\n\n理解 CQRS 的关键是将读取数据与写入数据分开。这样您就可以根据需要优化数据库：您的写入数据库是高度规范化的，因此您可以轻松确保一致性。相比之下，您的读取数据库是非规范化的，这使得您的读取变得极其简单和快速：它们都变得SELECT * FROM \xe2\x80\xa6有效。
假设像 StackOverflow 这样的网站的读取次数多于写入次数，这很有意义，因为它允许您优化系统以实现快速响应和出色的用户体验，同时又不会牺牲一致性。
\n\n此外，如果与事件溯源相结合，这种方法还有其他好处，但对于单独的 CQRS 来说，仅此而已。
\n\n无耻插件：我和我的团队创建了对 CQRS、DDD 和事件溯源的全面介绍，也许这也有助于提高理解。详情请参阅本网站。
\n