我正在(重新)设计大型应用程序，我们使用基于DDD的多层架构。
我们有带有数据层(存储库的实现)、领域层(域模型和接口的定义——存储库、服务、工作单元)、服务层(服务的实现)的MVC。到目前为止，我们在所有层上使用域模型(主要是实体)，并且仅将dto用作视图模型(在控制器中，服务返回域模型，控制器创建视图模型，并将其传递给视图)。
I'v read countless articles about using, not using, mapping and passing DTOs. I understand that there's no any definitive answer, but I'm not sure if it's ok or not returning domain models from services to controllers. If I return domain model, it's still never passed to the view, since controller always creates view-specific view model - in this case, it seem legit. On the other hand, it doesn't feel right when domain model leaves business layer (service layer). Sometimes service needs to return data object that wasn't defined in the domain and then we either have to add new object to the domain that isn't mapped, or create POCO object (this is ugly, since some services return domain models, some effectively return DTOs).
The question is - if we strictly use view models, is it ok to return domain models all the way to controllers, or should we always use DTOs for communication with service layer? If so, is it ok to adjust domain models based on what services need? (Frankly I don't think so, since services should consume what domain has.) If we should strictly stick to DTOs, should they be defined in service layer? (I think so.) Sometimes it's clear that we should use DTOs (e.g., when service performs lot of business logic and creates new objects), sometimes it's clear that we should use just domain models (e.g., when Membership service returns anemic User(s) - it seems it wouldn't make much sense to create DTO that is the same as domain model) - but I prefer consistency and good practices.
文章域vs DTO vs ViewModel -如何以及何时使用它们?(以及其他一些文章)与我的问题非常相似，但它没有回答这个问题。我应该用EF在存储库模式中实现dto吗?也类似，但它不处理DDD。
免责声明:我不打算仅仅因为任何设计模式的存在而使用它，另一方面，我想使用好的设计模式和实践，因为它有助于设计应用程序作为一个整体，有助于分离关注点，即使使用特定的模式不是“必要的”，至少目前是这样。
我来晚了，但这是一个如此常见而重要的问题，我觉得有必要做出回应。
你所说的“服务”是指Evan在蓝皮书中描述的“应用层”吗?我假设您知道，在这种情况下，答案是它们不应该返回dto。我建议阅读蓝皮书的第4章，标题为“隔离领域”。
在这一章中，Evans阐述了以下关于层次的内容:
把一个复杂的程序划分成几层。在每一层中开发一个内聚的设计，它只依赖于下面的层。
这是有充分理由的。如果您使用部分顺序的概念作为软件复杂性的度量，那么让一层依赖于它上面的一层会增加复杂性，从而降低可维护性。
将此应用于您的问题，dto实际上是用户界面/表示层所关注的适配器。请记住，远程/跨进程通信正是DTO的目的(值得注意的是，Fowler在那篇文章中也反对将DTO作为服务层的一部分，尽管他不一定是在谈论DDD语言)。
如果应用程序层依赖于这些dto，那么它就依赖于它上面的一层，复杂性就会增加。我可以保证这会增加维护软件的难度。
例如，如果您的系统与其他几个系统或客户端类型进行接口，每个系统或客户端类型都需要自己的DTO，该怎么办?如何知道应用程序服务的方法应该返回哪个DTO ?如果您所选择的语言不允许基于返回类型重载方法(在本例中是服务方法)，您将如何解决这个问题呢?而且，即使您找到了一种方法，为什么要违背应用层来支持表示层关注点呢?
在实践中，这是朝着意大利面条式架构的方向迈进的一步。我亲身经历过这种权力下放及其结果。
在我目前工作的地方，应用程序层中的服务返回域对象。我们不认为这是一个问题，因为界面(即UI/表示)层依赖于域层，它在它下面。此外，这种依赖被最小化为“仅引用”类型的依赖，因为:
a)接口层只能将这些域对象作为调用应用层获得的只读返回值访问
b)应用层服务上的方法只接受该层定义的“原始”输入(数据值)或对象参数(必要时减少参数计数)。具体来说，应用程序服务从不接受域对象作为输入。
接口层使用在接口层本身定义的映射技术从域对象映射到dto。这再次使dto集中于由接口层控制的适配器。
当域模型离开业务层(服务层)时，感觉不对
让你觉得你在把内脏掏出来，对吧?根据Martin Fowler的说法:服务层定义了应用程序的边界，它封装了域。换句话说，它保护了定义域。
有时服务需要返回域中未定义的数据对象
您能否提供此数据对象的示例?
如果我们应该严格遵循dto，那么它们应该在服务层定义吗?
是的，因为响应是服务层的一部分。如果它被定义为“其他地方”，那么服务层需要引用该“其他地方”，从而为您的千层面添加一个新层。
是否可以将域模型一直返回到控制器，或者我们应该始终使用dto与服务层通信?
DTO是一个响应/请求对象，如果您使用它进行通信，那么它是有意义的。如果你在表示层(MVC-Controllers/View, WebForms, ConsoleApp)中使用域模型，那么表示层与你的域紧密耦合，域中的任何变化都需要你改变控制器。
创建与域模型相同的DTO似乎没有多大意义)
这是DTO的缺点之一。现在，您正在考虑复制代码，但随着项目的扩展，它将变得更有意义，特别是在不同团队被分配到不同层的团队环境中。
DTO可能会给应用程序增加额外的复杂性，但层也是如此。DTO是系统的一个昂贵功能，它们不是免费的。
为什么使用DTO
本文提供了使用DTO http://guntherpopp.blogspot.com/2010/09/to-dto-or-not-to-dto.html的优点和缺点
总结如下:
何时使用
用于大型项目。
项目寿命10年以上。
战略，关键任务应用。
大型团队(5人以上)
开发人员在地理上分布。
域和表示是不同的。
减少开销数据交换(DTO的最初目的)
何时不使用
小型至中型项目(最多5人)
项目生命周期为2年左右。
GUI、后台等没有单独的团队。
反对DTO的理由
代码复制。
开发时间成本，调试成本。(使用DTO生成工具http://entitiestodtos.codeplex.com/)
您必须始终同步这两个模型。(就我个人而言，我喜欢这个，因为它有助于了解变化的涟漪效应)
开发成本:额外的映射是必要的。(使用自动绘图器，如https://github.com/AutoMapper/AutoMapper)
为什么数据传输对象(dto)是反模式?
DTO参数
如果没有DTO，表示和域是紧密耦合的。(这适用于小型项目。)
接口/ API稳定
可以通过返回只包含绝对需要的属性的DTO来为表示层提供优化。使用linq投影，你不需要拉出整个实体。
为了降低开发成本，请使用代码生成工具
