design-patterns - CQRS:按需构建的阅读模型？

Question

据我了解，CQRS 提倡将读取模型与域模型分离，并为每个必要的域模型投影设置一个特定的读取模型。

从使用角度来看，读取模型的存储和检索方式应该是透明的——您发出查询并获取读取模型，而无需关心它是如何制作的。

许多示例和文章使用单独的表来存储读取模型并通过响应域模型更改来重新生成它们。

由于以下原因，我不太喜欢这种方法:

并非经常需要所有可能的读取模型；

需求变更可能会使现有的读取模型失效，因此所有这些模型都需要重新生成；

如果由于某种原因读取模型包含无法在生成时存储但需要计算的属性，则您将被迫使用存储过程/函数/ View ；

由于读取模型与域模型分开，以防在域模型更改时使用应用程序级缓存，因此您需要通知所有应用程序旧的读取模型需要从缓存中清除；

有时，完全非规范化复杂对象图是不可能也不可取的，因此您需要读取与特定域实体版本一致的模型，即它们需要在同一事务中生成；

某些域实体具有频繁更改但需要包含在每个读取模型中的属性。

基于此，我考虑让查询服务应该:

对于需要频繁生成和/或域实体的简单投影的读取模型:不存储它们，而是通过查询数据库中的域模型实体通过 ORM 生成它们；

对于不需要频繁生成且复杂的域实体投影的读取模型，生成它们并存储在数据库表中。

我也看到有些人建议将读取模型存储为 blob。将读取模型存储为 blob 的问题在于，如果您需要搜索它们，您将需要提取用于索引的属性，如果您需要全文搜索，您甚至必须以全文可以理解的格式存储它们工具。

如您所见，我基本上希望读取模型仅在查询执行后存在，而不是基于域更改事件生成。 CQRS 可以接受这个解决方案吗？我研究 CQRS 的原因是通过将可缓存的 View 模型与用户操作处理分开来改进应用程序架构，让 AJAX 启用 Web 应用程序在用户操作后异步更新，并减少初级开发人员通过将业务逻辑全部放置来生成不可维护代码的空间在我看来，甚至不忠实地实现 CQRS 似乎是朝着正确方向迈出的良好一步。

Answer 1

CQRS 不要求将读取模型存储在单独的表(或文档，如果您使用文档数据库)中，尽管这通常是一种很好的方法并且与事件溯源结合使用效果很好。例如，读取模型可以由数据库 View 或 ORM 查询支持。

将 CQRS 引入遗留系统的一部分时，这可能是一个很好的方法。

您在这里建议的方法之前已经被建议过，例如参见 this post by Ayende ;我认为它被称为“瘦读模型”或类似的。我会说去吧。

你可能有兴趣阅读

Jimmy Bogard's article on myths in CQRS .

Ayende 的“限制你的抽象”系列帖子，starting here