白天生成的一些退款在白天持续存在,退款包括订单ID和1个或多个LineItemId.我需要在一天结束时将这些(在Windows服务中)合并到信用卡,礼品卡,奖励卡等中.
我一直在阅读Mark Seemann’s book并且可以看到使用Composition Root沙沙作响对象图的好处.
整合过程本身就是我需要做最多组合的地方.
我不明白的是这个整合逻辑应该在哪里结束？我可以假设无论合并逻辑在哪里结束,我仍然只在组合根中使用Unity之类的东西,那组合应该很早就发生了吗？
很高兴提供更多信息或酌情澄清！
解决方法
The consolidation process itself is where I need to do the most composition.
那么,您的意思是在系统中创建数据的过程是创建大多数域对象的位置吗？
这是有道理的,并且与大多数应用程序一致.
What I don’t understand is exactly where this consolidation logic should end up?
合并逻辑将由一个或多个服务组件提供,这些组件可能使用一个或多个repository组件和一个或多个unit of work组件.该服务将在组合根中组成,您最终创建的任何存储库/工作单元也将组成.
数据本身是完全动态的.您无法构建应用程序以静态地了解数据的布局,因此您无法在合成根中进行组合.你也不应该尝试.相反,您的代码可能使用ORM来定义或映射到域数据对象之间的关系模式.
然后,您可以使用存储库/工作单元从存储中检索数据.您还可以使用您的UI /服务来创建新数据 – 对于纯粹数据的域对象并不保证没有依赖关系.将新数据或修改后的数据保留到存储库/工作单元.
如果这让你感到畏缩,你总是可以使用从合成根注入的工厂模式来创建这些对象.但是,如果您将低级别域对象的结构设置为DTOs,那么这对您来说不会有太大的影响.
因此,您不必使用Unity来提供所有内容,并且您不必在组合根目录中创建系统中的所有对象.但是您应该尝试在组合根中组合系统的静态部分,甚至是静态可配置的系统动态部分.这很好地映射到像Unity这样的DI容器.
