DDD/DI（Unity）/ .NET /组合根 - 域服务

Question

我有一个标准的Order/OrderLineItem设置。

一天中产生的退款数量在一天中持续存在，退款包含一个订单ID和一个或多个LineItemId's。我需要在一天结束时将这些（在Windows服务中）合并到适当的信用卡，礼品卡，奖励卡等。

我一直在阅读Mark Seemann's book，并可以看到使用Composition Root沙漏一个对象图的好处。

整合过程本身就是我需要做最多构图的地方。

我不明白的是这个合并逻辑应该在哪里结束？我可以假设，无论合并逻辑结束的位置如何，我仍然只在组合根目录中使用类似Unity的组合，并且组合应该很早就发生？

欢迎提供更多信息或澄清！

Answer 1

整合过程本身就是我需要做最多构图的地方。

所以，你的意思是在你的系统中创建数据的过程是最多域对象被创建的地方吗？

这是有道理的，并符合大多数应用程序。

我不明白这个合并逻辑究竟应该在哪里结束？

固结逻辑将通过一个或多个服务组件，即有可能利用一个或多个组件repository和一种或多种unit of work部件来提供。该服务将在组合根中组成，您最终创建的任何存储库/工作单元也将组成该服务。

数据本身是完全动态的。您不能将应用程序构造为静态地知道数据的布局，因此您无法将它组合到组合根中。你也不应该尝试。相反，您的代码可能使用ORM来定义或映射到您的域数据对象之间的关系模式。

然后，您可以使用存储库/工作单元从存储中检索数据。您还可以使用您的用户界面/服务使用new来创建新数据 - 对于纯粹是数据的域对象并不保证没有依赖关系。将新数据或修改后的数据保存到存储库/工作单元。

如果这让你畏缩，你总是可以使用从组合根注入的工厂模式来创建这些对象。但是，如果您将低级别域对象的结构设置为DTOs，那么即使有，也不会给您带来太多收入。

因此，您不必使用Unity来提供所有内容，也不必在组合根中创建系统中的每个对象。但是，您应该尝试编写系统的静态部分，或者甚至可以在组合根目录中配置静态可配置的系统动态部分。这非常适合像Unity这样的DI容器。

Answer 2

如果您的退款项目只是数据容器或者对服务没有任何依赖关系的实体，您可以简单地使用新建立一个实例。

如果它们具有依赖关系并且必须由IoC容器创建，并且在启动时无法完成，那么您将需要使用工厂接口。此工厂接口包含一个CreateRefund方法，该方法将所有必需的参数传递给创建的实例。该接口在其使用者的命名空间/程序集中定义。

该接口的实现取决于IoC容器。一些容器提供了接口由容器自动实现的功能，只需在配置中指定它即可。其他像Unity一样需要手动执行。此实现位于组合根中，作为容器配置的一部分。让实现获取容器的实例并使用它创建请求的Refund实例。

这样，您访问容器的唯一位置在Composition Root中。