DTO pode ser considerado como objetos de negócios (com comportamento)?

5

Com base nesta pergunta e sua resposta:

Objeto na camada de negócios igual ao DTO com lógica

Eu quero perguntar:

E se, em vez de DAL, eu estiver recebendo dados de um serviço remoto (API) por meio de DTOs. Meus DTOs aqui representam praticamente todos os objetos de negócios com todos os relacionamentos entre eles. Embora haja BOs na API que estou chamando, não posso colocar o comportamento de que preciso, pois é específico para mim. Como posso lidar com isso?

se não houver comportamento no DTO e daí? Este olhar de baixa qualidade

(API) < - DTO - > (mappingService) < - objeto de domínio - > (domainService) < - DTO - > (UI) ??

    
por Mohamed Amine Mrad 10.06.2017 / 02:32
fonte

1 resposta

3

Existem vários padrões de arquitetura para sua escolha:

Basicamente, combinar seu DTO com a lógica de domínio se parece muito com um registro ativo. É uma solução viável se o seu modelo de domínio for simples e se o objeto de domínio estiver muito próximo do DTO.

No entanto, esteja ciente de suas principais desvantagens:

  • você não se beneficia mais do desacoplamento oferecido pelo DTO. Um DTO isola seu modelo de domínio interno, a partir da implementação de back-end, e permite que cada um evolua no seu próprio ritmo.
  • não está realmente alinhado com o princípio de design limpo de responsabilidade única

E atenção: use-o somente se o modelo de domínio for simples. Não é uma boa idéia se um objeto é simples, mas todo o modelo seria bastante complexo, porque os registros ativos levantam muitos problemas se você precisar combiná-lo com unidade de trabalho, um mapa de identidade ou outro patterns da arquitetura de aplicativos corporativos .

    
por 10.06.2017 / 17:10
fonte