Domain driven design 影响域设计的UI关注点

我有一个相当简单的领域，确定了大约7-8个主要实体，这些实体可能是它们自己的聚合根。但是将会有一个UI屏幕，它将列出系统中所有对象的并集，这意味着所有聚合的并集

我想到的一种方法是使用组合，即所有其他聚合根都引用的元数据聚合，它将是一个独立的实体。因此，对于这个屏幕，我可以查询这个聚合，我移动到这个新聚合的字段是需要显示在“所有对象”网格中的公共字段

另一种方法是使用应用程序服务方法，通过查询其他存储库、在应用程序层合并列表以及处理分页等，为“所有对象”屏幕构建必要的列表

我对第一个解决方案感到不安，因为我看到一个UI用例影响了我的解决方案 域设计，但数据库做的是处理分页、合并列表等繁重的工作 而且没有连接，所有这些信息都是通过一个简单的查询收集到的

第二种解决方案虽然看起来更整洁，但在易用性和性能方面却有所欠缺

---

请告知。

在这种情况下，我建议使用基本上是价值对象或DTO，专门用于读取场景。使用读取模型是保持实体和AR干净的一种模式。至于如何创建读取模型，基本上如您所述，您有两个选项。一种是让一个存储库返回满足给定视图要求的单个读取模型。这将允许您利用数据库提高性能。另一个选项是从应用程序服务级别的多个存储库或服务或表示层的事件组合读取模型。这种方法更具可扩展性，因为数据不必来自同一个数据源。

我认为您刚才描述了一种读写分离的情况（您知道，称为CQR的小模式）。“所有对象”数据需要有多新鲜？您可以选择执行显式异步投影，或者在数据上定义视图（有点像元数据的用途（顺便说一句，它不是聚合）），或者甚至在代码中使用不同的路径（查询）来获取所需的数据。