Tudo bom Rafael? Agradeço muito seu comentário.

Esse é um padrão que gera discussões entre os desenvolvedores. Apesar dele ter benefícios, como os mostrados no artigo, ele realmente deixa o código mais verboso, indo contra o famoso conceito DRY (Don’t repeat yourself).

Realmente sua solução de tratar a requisição na classe de serviço funciona perfeitamente.

Acho que um ponto legal do padrão DTO é que, seguindo o exemplo do artigo, o atributo admin não existe na classe UsuarioDTO, logo, não tem a menor chance desse valor ser alterada por usuários do seu sistema.

Seguindo esse pensamento, removemos a responsabilidade do desenvolvedor de ter que verificar se o campo admin foi enviado na requisição.

Na minha opinião isso é uma coisa boa, acho que abre menos espaço para erros por falta de validação.

Mas realmente o código fica mais verboso. Contando um pouco a respeito da minha experiência pessoal, eu não costumo usar o padrão DTO em todas as requisições.

Uso quando preciso montar objetos extremamente complexos, eu simplifico em um DTO com atributos simples para facilitar a vida do desenvolvedor front-end do time rs. Fica mais fácil de montar o corpo da requisição.

Também uso esse padrão quando possuo muitos atributos sensíveis no objeto, prefiro não ter que me preocupar com isso no meu serviço.

Concluindo, acho que é necessário avaliar, dependendo do problema que se esta enfrentando, se vale a pena aumentar um pouco a verbosidade do seu código usando o DTO ou se é mais efetivo validar na classe de serviço mesmo.

Agradeço novamente pelo seu comentário, acho que contribuiu bastante com o artigo. Espero ter conseguido adicionar alguma informação útil nessa resposta.

Fico aberto a novos comentários. Valeu!