聚合之间的域驱动设计查询
Domain Driven Design query between aggregates
我是 DDD 的新手，希望得到您的建议。
在我的 UI 中，我需要使用 EF Core 查看来自 2 aggregates.Im 的数据，正如我所读，最好在实体之间只保留一个导航，以免混合两个聚合并避免由于循环引用而导致的序列化问题.
我该如何查询？
每当我需要来自 2 个聚合的数据时，是否需要创建一个新视图？
如果需要创建视图，这个视图可以存在于哪一层？在基础架构持久层或域中？
谢谢
How should I make the query?
使用您可以使用的最简单、最快速的技术。我的意思是：如果使用 EF Core 构建查询需要多个步骤和大量额外对象，请更改方法并尝试使用直接 SQL 请求。它是查询，您可以快速测试并且可以在需要时同样快速地进行更改。
Do I need to create a new view whenever I need data from 2 aggregates?
你不知道。通过视图，您可以隐藏（在视图中）读取数据的复杂性（在每次要显示的数据应该更改时更改数据库的代码），以及您管理实体的 illusion/feeling 。或者当然应该清楚数据来自视图。另一方面，查询更多地与代码相关（要更改显示的数据，您只需更改查询），但您也“直接”显示该数据来自多个来源。
注意：我在几年前使用过 EF Core，并且用于一个非常简单的项目。如果使用 view 你的意思是 EF Core 的视图，那么我会说是。但前提是构建它不需要多个 steps/joins 来收集信息。当看起来代码开始有点太复杂而无法显示一些数据时，我总是会考虑直接方法。
这里，无论如何，事情可以变得非常深入：您是否将所有实体（根）都放在同一个项目中？或者你有几个微服务？使用微服务，您如何共享数据以及如何存储数据？也许查询不可行，或者它读取了部分旧数据。如您所见，当您必须读取数据时，需要考虑几件事。
If needs to create views in which layer this view can exist? In infrastructure persistance layer or domain?
如前所述，如果您指的是 EF Core 中的视图，我会非常靠近您要使用它的层。但是，这可能取决于。你可以看看here.
我个人使用 3 层：域、应用程序和基础架构。我的视图位于应用程序层，因为我有多个查询可重复用于不同的目的。但在进入基础设施（请求所在的位置）之前，我将结果转换为 UI.
所需的格式
DDD 是关于将所有业务逻辑放在一起，否则这些业务逻辑分布在多个实体、服务甚至控制器中。使用此解决方案，域提供的所有操作都可以在不需要域本身外部的额外逻辑的情况下执行。当然你需要实现域将要使用的服务，这是显而易见的。
另一方面很清楚，至少对我来说，重用仅限于域本身。我的意思是：
- 我可以构建一个大查询，从不同来源收集大量信息，并将其重复用于多个 UI 视图，但我必须准备好为我拥有的东西付出代价每次 UI 中的某些内容发生变化时触摸（无论如何我需要将其转换为与视图相关的对象）；
- 我可以构建用于 1、2（如果它们相同）UI 视图的小型专用查询，付出更多代码的代价（但简单且专用，并且测试速度非常快!) 维护（这里查询可以产生close to/equal来查看相关对象）。
第二种方法是CQRS的基础，我更喜欢这种方法。请记住，即使没有事件存储和最终一致性，您也可以执行 CQRS：您只需要一部分，而不是全部。我们设计是为了简化我们的生活，而不是让它们变得更难。
我是 DDD 的新手，希望得到您的建议。 在我的 UI 中，我需要使用 EF Core 查看来自 2 aggregates.Im 的数据，正如我所读，最好在实体之间只保留一个导航，以免混合两个聚合并避免由于循环引用而导致的序列化问题. 我该如何查询？ 每当我需要来自 2 个聚合的数据时，是否需要创建一个新视图？ 如果需要创建视图，这个视图可以存在于哪一层？在基础架构持久层或域中？
谢谢
How should I make the query?
使用您可以使用的最简单、最快速的技术。我的意思是：如果使用 EF Core 构建查询需要多个步骤和大量额外对象，请更改方法并尝试使用直接 SQL 请求。它是查询，您可以快速测试并且可以在需要时同样快速地进行更改。
Do I need to create a new view whenever I need data from 2 aggregates?
你不知道。通过视图，您可以隐藏（在视图中）读取数据的复杂性（在每次要显示的数据应该更改时更改数据库的代码），以及您管理实体的 illusion/feeling 。或者当然应该清楚数据来自视图。另一方面，查询更多地与代码相关（要更改显示的数据，您只需更改查询），但您也“直接”显示该数据来自多个来源。
注意：我在几年前使用过 EF Core，并且用于一个非常简单的项目。如果使用 view 你的意思是 EF Core 的视图，那么我会说是。但前提是构建它不需要多个 steps/joins 来收集信息。当看起来代码开始有点太复杂而无法显示一些数据时，我总是会考虑直接方法。
这里，无论如何，事情可以变得非常深入：您是否将所有实体（根）都放在同一个项目中？或者你有几个微服务？使用微服务，您如何共享数据以及如何存储数据？也许查询不可行，或者它读取了部分旧数据。如您所见，当您必须读取数据时，需要考虑几件事。
If needs to create views in which layer this view can exist? In infrastructure persistance layer or domain?
如前所述，如果您指的是 EF Core 中的视图，我会非常靠近您要使用它的层。但是，这可能取决于。你可以看看here.
我个人使用 3 层：域、应用程序和基础架构。我的视图位于应用程序层，因为我有多个查询可重复用于不同的目的。但在进入基础设施（请求所在的位置）之前，我将结果转换为 UI.
所需的格式DDD 是关于将所有业务逻辑放在一起，否则这些业务逻辑分布在多个实体、服务甚至控制器中。使用此解决方案，域提供的所有操作都可以在不需要域本身外部的额外逻辑的情况下执行。当然你需要实现域将要使用的服务，这是显而易见的。
另一方面很清楚，至少对我来说，重用仅限于域本身。我的意思是：
- 我可以构建一个大查询，从不同来源收集大量信息，并将其重复用于多个 UI 视图，但我必须准备好为我拥有的东西付出代价每次 UI 中的某些内容发生变化时触摸（无论如何我需要将其转换为与视图相关的对象）；
- 我可以构建用于 1、2（如果它们相同）UI 视图的小型专用查询，付出更多代码的代价（但简单且专用，并且测试速度非常快!) 维护（这里查询可以产生close to/equal来查看相关对象）。
第二种方法是CQRS的基础，我更喜欢这种方法。请记住，即使没有事件存储和最终一致性，您也可以执行 CQRS：您只需要一部分，而不是全部。我们设计是为了简化我们的生活，而不是让它们变得更难。