我是 DDD 的新手，希望得到您的建议。 在我的 UI 中，我需要查看来自 2 个聚合的数据。我使用 EF Core 并且我已经阅读了它更好地在实体之间只保留一个导航，因此不要混合两个聚合并避免由于循环引用而导致的序列化问题。 我应该如何进行查询？ 每当我需要来自 2 个聚合的数据时，是否需要创建新视图？ 如果需要创建视图，该视图可以存在于哪一层？在基础架构持久层或域中？
谢谢
【问题讨论】：
标签： c# entity-framework-core domain-driven-design
我应该如何进行查询？
借助您可以使用的最简单、最快的技术。我的意思是：如果使用 EF Core 构建查询需要几个步骤和大量额外对象，请更改方法并尝试使用直接 SQL 请求。它是查询，您可以快速测试并且可以在需要时进行同样快速的更改。
当我需要来自 2 个聚合的数据时，是否需要创建新视图？
你没有。通过视图，您可以隐藏（在视图中）读取数据的复杂性（在每次要显示的数据应该更改时更改数据库的代码），并产生您管理实体的错觉/感觉。或者当然应该清楚数据来自视图。另一方面，查询与代码更相关（要更改显示的数据，您只需更改查询即可），但您也“直接”显示该数据来自多个来源。
注意：我几年前就使用过 EF Core，并且是一个非常简单的项目。如果使用 view 您的意思是 EF Core 的视图，那么我会说是。但前提是构建它不需要几个步骤/连接来收集信息。当代码看起来有点过于复杂而无法显示某些数据时，我总是会考虑直接的方法。
在这里，无论如何，事情可能非常深入：您的所有实体（根）是否都在同一个项目中？或者你有几个微服务？使用微服务，您如何共享数据以及如何存储它？也许查询不可行，或者它读取部分旧数据。如您所见，当您必须读取数据时，需要考虑几件事情。
如果需要创建视图，该视图可以存在于哪一层？在基础架构持久层或域中？
如前所述，如果您指的是 EF Core 中的视图，我会非常靠近您将要使用它的层。但是，这可能取决于。你可以看看here。
我个人使用 3 层：域、应用程序和基础架构。我的视图位于应用程序层，因为我有几个查询可以重复用于不同的目的。但在进入基础架构（请求所在的位置）之前，我将结果转换为 UI 所需的格式。
DDD 是将分散在多个实体、服务甚至控制器上的所有业务逻辑组合在一起。使用此解决方案，可以执行域提供的所有操作，而无需域本身之外的额外逻辑。当然，您需要实现该域将要使用的服务，这是显而易见的。
另一方面，至少对我而言，重用仅限于域本身。我的意思是：
第二种方法是 CQRS 的基础，我更喜欢这种方法。请记住，即使没有事件存储和最终一致性，您也可以执行 CQRS：您只是参与其中的一部分，而不是全部。我们的设计是为了简化我们的生活，而不是让生活变得更艰难。
【讨论】：