DDD中实体构造的资源查找

Question

我对DDD很新，这就是我的困境：

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

我在这里有几个选择

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

哪个选项是正确的？这里真正突出的是通过其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上的帖子，深入讨论这些主题。