我正在尝试使用 DDD 模式，作为持久存储，我正在考虑使用 NoSQL 数据库，如 LiteDB、RavenDB 或 DocumentDB。
与关系数据库相比，我的一个优势是我的域模型（整个聚合）可以序列化为 JSON 文档并存储在数据库中，避免了域模型到数据模型的映射。
但是为了在屏幕上显示数据而读取数据呢？我的 UI 显示基于视图模型的视图，但如何构建它们？我是否通过查询文档数据库。我的领域模型，然后将其映射到视图模型？
我问这个，因为它通常被提到“不要使用你的域模型进行查询（读取模型）”。
【问题讨论】：
标签： domain-driven-design nosql
与关系数据库相比，我的一个优势是我的域模型（整个聚合）可以序列化为 JSON 文档并存储在数据库中，避免了域模型到数据模型的映射。
是的，这很好。
但是为了在屏幕上显示数据而读取数据呢？我的 UI 显示基于视图模型的视图，但如何构建它们？我是否通过查询文档数据库。我的域模型，然后将其映射到视图模型？
是的。有趣的问题是何时。
您可以与请求同步地完成这项工作。
您可以与请求同步执行该工作，但缓存结果，以便同一视图的后续查询更快。
您可以异步完成这项工作——使用后台进程将视图加载到缓存中，以便所有查询都很快。
基本思想是，每次您向文档写入更改时，您都会向异步进程发出更改已发生的信号，然后该进程会加载更新缓存视图所需的数据。
例如，“缓存”可能是保存您最近组合的视图模型的文档存储。
缓存的视图还可能包含允许在请求时确定是否需要重建视图的元数据。在考虑缓存元数据时，RFC 7234 可能是一个不错的起点。
正如 Pawel 所说，分离写入模型和读取模型是 cqrs 的大主题。有很多文献可用。我建议从Martin Fowler's overview 开始。
【讨论】：
了解您的域模型由行为和状态组成，这一点很重要。唯一需要坚持的就是状态。
当您意识到这一点时，您还会发现在聚合状态上运行查询并不可怕。但是你绝对不应该使用你的存储库来编写读取/查看模型——简单的查询就足够了。在那里，将您的域对象状态分成简单的 DTO（文档）变得很方便，您将其存储在数据库中，并将它们作为属性保存在您的域对象中。这与书中显示的有点不同，但在实践中效果很好。如果您的封装足够好并且不会编写序列化和持久性测试，您至少将不再担心。 This article 在由状态对象支持的域对象部分下提到了它。
【讨论】：