Estou (re) projetando aplicativos em larga escala, usamos arquitetura multicamada baseada em DDD.
Temos MVC com camada de dados (implementação de repositórios), camada de domínio (definição de modelo de domínio e interfaces - repositórios, serviços, unidade de trabalho), camada de serviço (implementação de serviços). Até o momento, usamos modelos de domínio (principalmente entidades) em todas as camadas e usamos DTOs apenas como modelos de exibição (no controlador, o serviço retorna modelos de domínio e o controlador cria um modelo de exibição, que é passado para a exibição).
Já li inúmeros artigos sobre como usar, não usar, mapear e transmitir DTOs. Entendo que não há resposta definitiva, mas não tenho certeza se está tudo bem ou não retornando modelos de domínio de serviços para controladores. Se eu retornar o modelo de domínio, ele ainda nunca será passado para a visualização, pois o controlador sempre cria um modelo de visualização específico da visualização - nesse caso, parece legítimo. Por outro lado, não parece certo quando o modelo de domínio sai da camada de negócios (camada de serviço). Às vezes, o serviço precisa retornar um objeto de dados que não foi definido no domínio e, em seguida, precisamos adicionar um novo objeto ao domínio que não está mapeado ou criar um objeto POCO (isso é feio, pois alguns serviços retornam modelos de domínio, alguns efetivamente retornar DTOs).
A questão é: se usarmos estritamente os modelos de exibição, não há problema em retornar modelos de domínio até os controladores ou devemos sempre usar DTOs para comunicação com a camada de serviço? Em caso afirmativo, é possível ajustar modelos de domínio com base em quais serviços precisam? (Sinceramente, acho que não, pois os serviços devem consumir o domínio que possui.) Se devemos seguir rigorosamente os DTOs, eles devem ser definidos na camada de serviço? (Acho que sim.) Às vezes, fica claro que devemos usar DTOs (por exemplo, quando o serviço executa muita lógica de negócios e cria novos objetos), outras vezes, fica claro que devemos usar apenas modelos de domínio (por exemplo, quando o serviço Membership retorna Usuário anêmico ( s) - parece que não faria muito sentido criar DTO igual ao modelo de domínio) - mas prefiro consistência e boas práticas.
Artigo Domínio vs DTO vs ViewModel - Como e quando usá-los? (e também alguns outros artigos) é muito parecido com o meu problema, mas não responde a essas perguntas. Artigo Devo implementar DTOs no padrão de repositório com EF? também é semelhante, mas não lida com DDD.
Isenção de responsabilidade: não pretendo usar nenhum padrão de design apenas porque existe e é sofisticado; por outro lado, gostaria de usar bons padrões e práticas de design também porque ajuda a projetar o aplicativo como um todo, ajuda na separação de preocupações, mesmo que o uso de determinado padrão não seja "necessário", pelo menos no momento.
Como sempre, obrigado.