使用域驱动设计的系统架构,域对象是否应该可用于所有层?

时间:2012-11-05 11:22:02

标签: domain-driven-design

  • views可以调用控制器
  • 控制器仅与视图和服务层(事务所在的位置)进行通信
  • 服务层对事务中包含的域对象进行一系列调用
  • 域对象包含对dao层的调用。
  • dao layer填充域对象并保留数据。

但我可以通过不同层传递域对象以通过getter访问数据,或者我是否必须使用dto - 包含特定于视图/用例的数据的减少域对象。在层周围传递域对象似乎鼓励打破层只能与指定的其他层进行通信的规则。但另一方面,那是DDD的重点吗?如果最好从域对象获取数据并放入dto,应该在哪里进行,控制器?

Domain-driven-design, am it doing it right

3 个答案:

答案 0 :(得分:2)

我个人总是使用查看模型(您的视图为DTO)。这有助于减少传递给您的视图的数据量,并避免意外泄露安全数据。

理论上,UI(或多个UI或Web服务)应该插在您的系统之上。例如,如果您通过Web服务公开系统,您可能还希望以某种方式展平和减少数据,以便不对域实体创建依赖关系(这样您可以在不破坏外部系统的情况下更改它们)并再次不要在您的域实体中公开任何ID或敏感数据。

我想这适用于任何开发实践,而不仅仅是DDD。

答案 1 :(得分:1)

你应该将域放在所有其他层旁边,因为它应该100%独立于其他所有层。因此你应该能够在任何地方使用它。

DDD中的服务只应在两个或多个不同的根聚合需要交互时使用。

至于交易,为什么不在UI层中使用TransactionScope?它仍然是无知的。

我个人直接在UI中使用存储库(因为DDD中的存储库是数据库抽象)

答案 2 :(得分:1)

虽然在规范的分层体系结构中确实应该尽可能划分区域,但是将域实体一直传递到UI似乎是我可以接受的,尤其是在表示层和域层位于同一层的简单应用程序中。它只需要UI有一个对域的引用,这不是那么令人震惊(反过来实际上会有问题)。

马克·西曼有一个blog post对这个问题有一些有趣的想法,尽管我不同意他的所有观点。