我有一个标准的Order / OrderLineItem设置。
在白天持续生成的一些退款，退款包括订单ID和1个或多个LineItemId。我需要在一天结束时将这些（在Windows服务中）合并到信用卡，礼品卡，奖励卡等中。
我一直在阅读Mark Seemann's book并且可以看到使用Composition Root沙沙作响对象图的好处。
整合过程本身就是我需要做最多的工作。
我不明白的是这个整合逻辑应该在哪里结束？我可以假设，无论合并逻辑在哪里结束，我仍然只在组合根中使用类似Unity的东西，那组合应该很早就发生了吗？
很高兴提供更多信息或酌情澄清！
答案 0 :(得分：3)
如果您的退款项目只是数据容器或与服务没有任何依赖关系的实体，您只需使用new创建实例。
如果它们具有依赖关系并且必须由IoC容器创建，并且您在启动时无法执行，那么您将需要使用工厂接口。此工厂接口包含CreateRefund方法，该方法获取要传递给创建的实例的所有必需参数。此接口在其使用者的名称空间/程序集中定义。
此接口的实现取决于IoC容器。某些容器提供的功能是容器自动实现接口，只需在配置中指定它即可。像Unity这样的其他人需要手动实现。此实现作为容器配置的一部分存在于组合根中。让实现获取容器的实例并使用它来创建请求的Refund实例。
这样，访问容器的唯一位置就是在Composition Root中。
答案 1 :(得分：3)
整合过程本身就是我需要做最多的工作。
那么，您的意思是在系统中创建数据的过程是创建大多数域对象的位置吗？
这是有道理的，并且与大多数应用程序一致。
我不明白的是这个整合逻辑应该在哪里结束？
整合逻辑将由一个或多个服务组件提供，这些组件可能使用一个或多个repository组件和一个或多个unit of work组件。该服务将在组合根中组成，您最终创建的任何存储库/工作单元也将如此。
数据本身是完全动态的。您无法构建应用程序以静态地了解数据的布局，因此您无法在组合根中进行组合。你也不应该尝试。相反，您的代码可能会使用ORM来定义或映射到域数据对象之间的关系模式。
然后，您可以使用存储库/工作单元从存储中检索数据。您还可以使用您的UI /服务使用new创建新数据 - 对于纯数据的域对象并不保证没有依赖关系，这一点并不遗憾。将新数据或修改后的数据保留到存储库/工作单元。
如果这让你感到畏缩，你总是可以使用从合成根注入的工厂模式来创建这些对象。但是，如果您将低级域对象的结构设置为DTOs，那么这对您来说不会有太大的收获。
因此，您不必使用Unity提供所有内容，也不必在组合根目录中创建系统中的所有对象。但是您应该尝试在组合根中组合系统的静态部分，甚至是静态可配置的系统动态部分。这很好地映射到像Unity这样的DI容器。