CQRS读取模型侧 - 规范化表

Question

我一直在阅读有关Command Query Responsibility Segregation（CQRS）以及这种模式如何适合我们当前的应用程序的内容。

说到阅读模型，我很清楚这些概念： “分离读写数据模型”，“由瘦读取层返回的平面非规范化数据”。在大多数情况下，我们使用相同的数据库（相同的读/写数据模型），在带有规范化表的SQL Server上运行，并在其上面使用公共分层应用程序。

那么，在这种情况下应用CQRS是否有任何价值？ 如果是这样，那么在阅读模型方面会是什么呢？

我想到的另一个问题是MVC应用程序从我的瘦读取层请求信息，这些信息暴露了扁平视图。暴露的数据仍然需要在呈现给用户之前进行结构化（加重），或者我错了吗？

祝你好运

Answer 1

CQRS不需要具有平坦的读取模型;这是CQRS可以允许您提供的好处，但它既不是必需的，也不是该方法的关键部分。

CQRS是关于分离（如果您遵循名称，则为隔离）。这是类固醇的命令查询分离原则（在我看来）。它为您提供的好处（在我的头脑中）是：

• 将您的读取操作与写入操作分开;
• 通过消息传递（例如命令，事件）在各层之间进行通信，以便您的图层清洁;
• 在您的图层中分离，应用单一责任原则（例如，您的域应用业务逻辑，您的命令处理路由命令，您的非规范化程序或事件处理程序（或您称之为的任何内容）将信息保存到您的读取存储等）。 / LI>
• 允许您让团队成员在应用程序的不同部分上工作，而不会在它们之间存在硬依赖关系;
• 等

因此，如果上述内容对您或您想要争取的事情很重要（并且您的应用程序的设计支持实施CQRS），那么CQRS将为您提供好处和价值。

CQRS有许多好处。对于每个问题，它都不是正确的解决方案，但是当星星对齐时，它是解决问题的好方法（即使您没有非规范化的读取存储，或事件存储，或异步模型等）。 / p>

我希望这有帮助！

Answer 2

在我的职业生涯中，我曾经多次加入多次联盟，当像CQRS和ES这样的结构出现并提供简化读取方面的简洁方法时，我跳了起来。不错的是，您可以获得许多好处，而无需实现通常与CQRS和ES相关的所有元素。将命令与查询分开可以简化代码。但是，当您开始使用反规范化器为您的应用程序构建读取模型时，您会突然意识到您的应用程序可以是多么简单，干净和高效。

如果有助于了解＆＃39;如何＆＃39;这个非规范化的工作看一下这篇文章（它附带了一个代码示例，可以看一下）：How to build a master details view with CQRS and ES。我希望你觉得这很有帮助。

Answer 3

如果允许您停止从域对象中投射读取模型，那么在同一（例如）第三范式数据库上应用CQRS仍然可以在读取端给出值。

这也允许您更好地将您的域专门化为（我假设）事务处理，这意味着可能不需要许多关系。