DTO vs. Domain Model, project organization

Question

I have a project with a repository, a service layer, using EF6 and code-first POCOs. In the CustomerRepository, I am doing several projection queries that return objects.

I understand that the code-first POCO's are what would be considered "Domain Models", but if I were to do a projection query into a different model, what is that model considered? An example of this would be the CustomerOrderStats. Is that still a Domain Model, or should that be considered a DTO model?

Example

Object returned from Repository:

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

Query in the Repository

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

Answer 1

It could be either one, really. The definition of a model vs. a DTO isn't really a matter of how you organize any given framework, but rather what that object represents in the domain. If it has rich functionality or business logic or is an active part of the actual business process, it's probably a model. If, on the other hand, it's just a container of properties to move values from one place to another, it's probably a DTO.

The key here is whether the object is an active part of the business process. And a good rule of thumb here is often the name of the object.

• Is it a name that non-technical business team members understand?
• Is it a term they use to describe what the business does? (Even a very small part of the business)
• Does it carry a meaning in the industry in general?

A DTO is generally something that exists for purely technical reasons. Component A needs to send data to Component B, but that operation is a technical one and not a business one. Data just needs to be, well, transferred. As a piece of the system, it's essentially built "from the bottom up" because it satisfies a low-level technical need.

A model describes a part of the business. It could be an element on a chart which defines the business process in non-technical terms, or an encapsulation of a business concept. As a piece of the system, it's essentially built "from the top down" because it is described generally by the business and then implemented specifically to meet that need.