【发布时间】:2012-12-07 22:41:53
【问题描述】:
背景: 为了我自己的清晰/自我教育,我正在尝试使用 TDD + DDD 实现一个简单的订单输入应用程序。我的主要目标是通过分离关注点来保持架构清洁。
我有四层(目前)...
具有 CustomerRepository 类的持久性/DAL,该类可以对“聚合根”、客户及其相关的订单和订单项执行 GetById、保存、操作。为了允许“穷人的依赖注入”
域/BLL 层包含“业务实体”类,这些类执行细粒度操作以帮助创建新订单,根据订单大小和客户位置应用税收、折扣、运输逻辑。
应用程序外观(应用程序服务/编排)包含厚实、粗粒度的类,用于编排“业务实体”并减少与演示文稿(以及可能的 WebServices 层)之间的交流。
表示层
此外,我想在关键层之间传递 POCO DTO ......尤其是在 Persistence=>Domain 层和 ApplicationFacade=>Presentation 层之间。所以,我有 CustomerDto、OrderDto、OrderItemDto 以及在共享包中定义的适当关系。
我想使用构造函数注入将 ICustomerRepository 的实现注入到客户“业务实体”类中,然后在“业务实体”上调用 Customer.Save() 以启动创建/更新过程,最终调用在 CustomerRepository 上保存方法。毕竟,客户是“聚合根”,拥有保存所需的所有信息……它也是注入的客户存储库的“守护者”。
问题: 这是我遇到障碍的地方。我希望保持域/BLL 层尽可能纯净,并避免将其耦合到任何第三方框架和 API,但是 Customer.Save() 方法需要翻译客户“聚合根”并将其所有 Orders 和 OrderItems 放入其 DTO 版本中,以传输到注入的 Persistence 层 CustomerRepository ...这是 Automapper 的工作。
问题是...如果我不将 Automapper 放在 Domain/BLL 层中,我不确定它应该放在 哪里。
尽管它的工作是编排,但把它放在 ApplicationFacade 中感觉不太合适。
把它放在 Domain/BLL 层肯定感觉不对,因为我想保持它的原始状态。
因此,我觉得我错过了一些东西……我在处理这个问题时对工作部分应该如何组合在一起来完成这项任务存在根本性的误解。有什么建议么? (请温柔一点,我对这一切都很陌生,对 SO 也很陌生。如果我需要展示我目前所拥有的一些代码,请告诉我。)
【问题讨论】:
标签: architecture domain-driven-design automapper layer