int*_*den 8 .net c# domain-driven-design dependency-injection unity-container
我有一个标准的Order/OrderLineItem设置.
白天生成的许多退款在白天持续存在,退款包括订单ID和1个或多个LineItemId.我需要在一天结束时将这些(在Windows服务中)合并到信用卡,礼品卡,奖励卡等中.
我一直在阅读Mark Seemann的书,可以看到使用Composition Root来勾勒对象图的好处.
整合过程本身就是我需要做的最多的组合.
我不明白的是这个整合逻辑应该在哪里结束？我可以假设,无论合并逻辑在哪里结束,我仍然只在组合根中使用类似Unity的东西,那组合应该很早就发生？
很高兴提供更多信息或酌情澄清!
整合过程本身是我最需要进行合成的地方。
那么，您的意思是在系统中创建数据的过程是创建大多数域对象的地方？
这是有道理的，并且符合大多数应用程序。
我不明白的是，这种合并逻辑到底应该结束在哪里？
整合逻辑将由一个或多个服务组件提供，这些组件可能利用一个或多个存储库组件以及一个或多个工作单元组件。该服务将在组合根中组合，您最终创建的任何存储库/工作单元也是如此。
数据本身是完全动态的。您无法构建应用程序以静态了解数据的布局，因此无法将其组合到组合根中。你也不应该尝试这样做。相反，您的代码可能会使用 ORM 来定义或映射到域数据对象之间的关系模式。
然后，您可以使用存储库/工作单元从存储中检索数据。您还可以使用 UI/服务来创建新数据new——对于纯数据的域对象来说，这没什么可耻的，并且保证没有依赖关系。将新的或修改的数据保留到存储库/工作单元。
如果这让您感到畏缩，您始终可以使用从组合根注入的工厂模式来创建这些对象。但是，如果您将低级域对象构造为DTO，那么这不会给您带来太多好处（如果有的话）。
因此，您不必使用 Unity 来提供所有内容，也不必在组合根中创建系统中的所有对象。但是您应该尝试在组合根中组合系统的静态部分，甚至是系统的静态可配置动态部分。这很好地映射到 Unity 等 DI 容器。
| 归档时间： |
|
| 查看次数： |
1037 次 |
| 最近记录： |