我正在尝试使用DDD模式，并且作为持久存储我正在考虑使用像LiteDB，RavenDB或DocumentDB这样的NoSQL数据库。DDD NoSQL存储和域模型与视图模型
的优点之一对我来说，在关系数据库，将是我的域模型（全聚集）可以序列化为JSON文件，并存储在一个数据库避免域模型到数据模型的映射。
但是，为了在屏幕上显示数据而读取数据呢？我的UI基于视图模型显示视图，但是如何构建视图？我是否通过查询文档数据库？我的域模型，然后将其映射到查看模型？
我这样问，因为它通常提到“不要使用你的域模型进行查询（读取模型）”。
的优点之一对我来说，在关系数据库，将是我的域模型（全聚集）可以序列化为JSON文件，并存储在一个数据库避免域模型到数据模型的映射。
是啊，这是很好的。
但是如何读取数据以便在屏幕上显示数据。我的UI基于视图模型显示视图，但是如何构建视图？我是否通过查询文档数据库？我的域模型，然后将其映射到查看模型？
是的。有趣的问题是当时。
您可以与请求同步执行该操作。
您可以与请求同步执行该操作，但会缓存结果，以便后续对相同视图的查询更快。
你可以做到这一点异步工作 - 利用后台进程加载的观点到缓存中，这样所有的疑问都很快。
的基本思路是，每次写更改文档时，你发出信号的变化已经发生异步处理，然后将处理加载它需要更新缓存的视图中的数据。
“缓存”可能是，例如，保存您最近组成的视图模型的文档存储。
缓存的视图也可以包括元数据，允许在要求的时间，以确定是否需要重建的观点。当考虑缓存元数据时，RFC 7234可能是一个很好的开始。
由于帕维尔指出，分离写模式和读模式是cqrs的大主题。有很多可用的文献很安静。我建议从Martin Fowler's overview开始。
我的项目很小，没有后端，一切都在本地运行，但我仍想尝试在某些部分上应用DDD。我觉得像CQRS和异步写/读会是一个矫枉过正。我宁愿在应用服务中构建我的虚拟机，就像Paweł提到的那样。目前我唯一的担心是如果我有一个聚合的几个属性和子集合，但我想检索一些属性以便在列表中显示这些数据，我该怎么做？ ... >> –
... >>获取整个聚合，然后建立一个虚拟机只有2个属性是完全浪费。我觉得我应该总是写两个版本的文件，一个用于细节，另一个用于清单。 –
重要的是要了解您的域模型包含行为和状态。你需要坚持的唯一的事情就是状态。
当你意识到这一点时，你也会发现聚合状态并不是可怕的运行你的查询。但是你绝对不应该使用你的存储库来组成读取/查看模型 - 简单的查询就足够了。在这种情况下，将域对象状态分离为简单的DTO（文档）会很方便，您将存储在数据库中，并将它们作为属性保存在域对象中。这与书中显示的有点不同，但实际上效果很好。如果封装足够好并且不会编写序列化和持久性测试，您至少不用担心。 This article在提到的域对象支持状态对象部分。
在您的应用程序服务中使用存储库从NoSQL数据库检索聚合，然后使用一些不同的视图模型将其传递到前端。如果您遇到像这样的问题，也请考虑获取有关CQRS的一些知识。 –