DDD中实体构造的资源查找

Question

我对 DDD 还很陌生，这是我的困境：

我必须保留一个引用实体 B 的实体 A（让我们认为两者都是实体根）。 UI 层通过 A_DTO（A 的 DTO 类）收集所有这些信息（在控制器处），将属性从 DTO 映射到 A 的新实例，现在为了在 A 中引用 B，UI 发送一个 id。当我在存储库后面使用 ORM 时，我想从 BRepository 查找 B 的对象实例，在我们正在构建的新 A 实例上填充引用，最后调用 ARepository.save(A instance)。

我有几个选择

1. 在 UI 层（在控制器或某种服务外观）中执行所有这些操作或
2. 在名为 createA 的 ApplicationService 甚至是域 Service 中执行此操作。

哪个选项是正确的??。这里真正突出的是通过其 id 查找 B 以获取对 A 对象设置的引用的过程，这可以同样被认为是保持 ORM 满足或保持域模型一致的过程。在 A 上设置 B 的引用的过程中可能存在一些隐含的业务规则和验证，我认为这些是这里做出决定的驱动点。

此外，这里可能更奇怪的是验证是否应该在创建实体的过程中编织，并通过可以通过 UI 向客户端冒泡的特定错误来说明构造函数和/或设置器并通过回购获得另一个级别的验证？或者作为控制器中发生的显式步骤？？

Answer 1

DTO 只是用于在 UI 层中传输数据的便利类。您使用 ID 来引用 B 的事实是 UI 层的实现细节。因此，将 DTO 映射到域对象应该是 UI 层/控制器的工作，包括将 ID 转换为引用。

另一方面，验证正确地属于领域层。在这方面，UI 的唯一工作是在域对象中设置值并显示由此产生的任何错误。

Answer 2

这两个选项都可以被视为正确，但我更倾向于选项 2，因为应用程序服务提供的封装有助于阅读和理解代码。它还可以更轻松地整合您的域的 API。支持选项 1 而不是 2 的论点是，由于使用应用程序服务而产生的额外封装层是不必要的复杂性，尽管您当然是评判者。验证通常体现在应用程序的多个层中，包括表示层和领域层。编写一次验证逻辑并在其他地方重用似乎很理想，实际上复制验证逻辑通常更容易。这意味着表示层，例如 ASP.NET MVC，有自己的视图模型验证声明。然后应用程序服务和域实体还应该执行该上下文中所需的任何验证。请查看我在 services in DDD 和 validation in DDD 上的帖子，以深入讨论这些主题。