DTO vs. 领域模型，项目组织答案

【问题标题】：DTO vs. Domain Model, project organizationDTO vs. 领域模型，项目组织
【发布时间】：2017-05-05 19:21:02
【问题描述】：

我有一个带有存储库、服务层、使用 EF6 和代码优先 POCO 的项目。在 CustomerRepository 中，我正在执行几个返回对象的投影查询。

我知道代码优先的 POCO 会被视为“域模型”，但如果我要对不同的模型进行投影查询，该模型会被视为什么？这方面的一个例子是CustomerOrderStats。那仍然是领域模型，还是应该被视为 DTO 模型？

例子

从存储库返回的对象：

public class CustomerOrderStats
{
   public string Name { get; set; }
   public int Count { get; set; } 
}

在存储库中查询

public CustomerOrderStats GetCustomerOrderStats(Guid customerGuid)
{
   return customers
        .Where(c => c.Guid == customerGuid)
        .Select(new CustomerOrderStats 
               { 
                  Name = c.Name,
                  Count = c.Orders.Count()
               };
}

【问题讨论】：

对我来说，您的 CustomerOrderStats 类只是一个包含一组属性的 DTO。领域模型通常倾向于包含行为/业务逻辑以保护不变量并强制执行业务规则。
如果某些东西是 POCO，它不会使它们成为 DTO。 DTO 的目的是提供对 DOMAIN 的简化视图。通常应用层使用DTO，业务层和数据层使用DOMAIN。

标签： c# domain-driven-design repository-pattern

【解决方案1】：

真的可以是其中之一。模型与 DTO 的定义实际上并不是您如何组织任何给定框架的问题，而是该对象在域中代表什么。如果它具有丰富的功能或业务逻辑，或者是实际业务流程的活跃部分，那么它可能是一个模型。另一方面，如果它只是一个将值从一个地方移动到另一个地方的属性容器，那么它可能是一个 DTO。

这里的关键是对象是否是业务流程的活跃部分。这里的一个好的经验法则通常是对象的名称。

是非技术业务团队成员都能理解的名称吗？
这是他们用来描述业务的术语吗？（即使是很小的一部分业务）
它在整个行业中是否具有意义？

DTO 通常是出于纯技术原因而存在的东西。组件 A 需要向组件 B 发送数据，但该操作是技术操作而不是业务操作。数据只需要传输即可。作为系统的一部分，它本质上是“自下而上”构建的，因为它满足了低级技术需求。

模型描述了业务的一部分。它可以是图表上以非技术术语定义业务流程的元素，也可以是业务概念的封装。作为系统的一部分，它基本上是“自上而下”构建的，因为它由业务部门进行一般性描述，然后专门实施以满足该需求。

【讨论】：