DDD / DI (Unity) / . net / Composition根域服务

巩固过程本身是我最需要做合成的地方。

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

这是有意义的，并且符合大多数应用程序。

我不明白的是这个合并逻辑应该在哪里结束?

整合逻辑将由一个或多个服务组件提供，它可能利用一个或多个存储库组件和一个或多个工作单元组件。该服务将在组合根目录中组合，就像您最终创建的任何存储库/工作单元一样。

数据本身是完全动态的。你不能构建你的应用程序来静态地了解数据的布局，因此你不能在你的组合根中组合它。你也不应该这么做。相反，您的代码可以使用ORM来定义或映射到域数据对象之间的关系模式。

然后您可以使用存储库/工作单元从存储中检索数据。您还可以使用您的UI/服务使用new来创建新数据-对于纯数据的领域对象来说，这并不奇怪，并且保证没有依赖关系。将新的或修改的数据持久化到存储库/工作单元。

如果这让你畏缩，你总是可以使用从组合根注入的工厂模式来创建这些对象。但是，如果您已经将低级域对象构造为dto，那么这不会给您带来太多好处。

所以你不需要使用Unity来提供所有的东西，你也不需要在你的系统中创建所有的对象。但是，您应该尝试在组合根目录中组合系统的静态部分，甚至是静态可配置的系统动态部分。

如果您的退款项只是数据容器或实体，不依赖于任何服务，您可以简单地使用new创建一个实例。

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

该接口的实现依赖于IoC容器。有些容器提供接口由容器自动实现的功能，只需在配置中指定即可。Unity等其他工具则需要手动执行。这个实现位于组合根中，是容器配置的一部分。让实现接受容器的一个实例，并使用它来创建请求的退款实例。

这样，你访问容器的唯一地方是在组合根目录