CQRS 读取模型端 - 规范化表答案

【问题标题】：CQRS read model side - normalized tablesCQRS 读取模型端 - 规范化表
【发布时间】：2014-10-07 22:20:17
【问题描述】：

我一直在阅读有关命令查询职责分离 (CQRS) 以及这种模式如何适合我们当前应用程序的信息。

当谈到读取模型时，我非常了解以下概念： “分离读写数据模型”，“瘦读层返回的平面非规范化数据”。在大多数情况下，我们被困在同一个数据库（同一个读/写数据模型）上，运行在带有规范化表的 SQL Server 上，上面有通用的分层应用程序。

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

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

最好的问候

【问题讨论】：

标签： cqrs

【解决方案1】：

CQRS 不需要扁平化读取模型；这是 CQRS 可以让您提供的好处，但它既不是必需的，也不是该方法的关键部分。

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

将读取操作与写入操作分开；
层之间通过消息传递（例如命令、事件）进行通信，以便您的层是干净的；
在您的层内分离，应用单一职责原则（例如，您的域应用业务逻辑，您的命令处理路由命令，您的非规范化程序或事件处理程序（或任何您称之为的）将信息持久保存到您的读取存储等）
允许您让团队成员处理应用程序的不同部分，而他们之间没有硬依赖；
等

因此，如果上述这些事情对您很重要或您想为之奋斗（并且您的应用程序的设计支持实现 CQRS），那么 CQRS 将为您带来好处和价值。

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

我希望这会有所帮助！

【讨论】：

【解决方案2】：

在我的职业生涯中，我曾多次与多个连接作斗争，以至于当出现像 CQRS 和 ES 这样的结构并提供了一种简洁的方式来简化读取方面时，我就跳了起来。好处是您可以获得许多好处，而不必实现通常与 CQRS 和 ES 相关的所有元素。仅将命令与查询分开就有简化代码的好处。但是，当您开始使用反规范化器为您的应用程序构建读取模型时，您会突然意识到您的应用程序是多么简单、干净和高性能。

如果有助于了解这种去规范化的“如何”工作，请查看这篇文章（它附带了一个代码示例以供参考）：How to build a master details view with CQRS and ES。希望对您有所帮助。

【讨论】：

【解决方案3】：

在相同（例如）第三范式数据库上应用 CQRS，如果它允许您停止从域对象投影读取模型，它仍然可以在读取方面为您带来价值。

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

【讨论】：