Atualmente muitos devs estão criando api’s rest fornecendo vários serviços, acontece que muitas vezes que necessita criar esses novos serviços é necessário que na maioria das vezes efetuar algumas validações necessarias na requisição, acontece que hoje existe um pequeno dilema onde deve ser efetuado essas validações, no controlador que possui o DTO de requisição através de bean validations ou via hardcode, deixar essa responsabilidade para o service (business) efetuar a validação ou efetuar a validação nos dois locais?
Onde atualmente vocês efetuam essa validações?
Vocês permitem que seus services conheçam seus DTO`s ?
Quando se trabalha com a ideia de serviços, pode-se trazer algumas noções da arquitetura orientada a serviços - SOA. Uma dessas premissas é a elaboração de um contrato de serviços padronizado e federado, de preferência. Com isso, cria-se uma camada/interface de comunicação entre um cliente e o serviço. A partir do momento em que se tem esse modelo canônico de dados bem formulado, as validações se tornam algo natural. Imagina que o serviço A se comunica com o serviço B por meio de uma classe controladora do serviços B. Sabe-se exatamente quais dados de entrada e saída do serviço, justamente por conta do contrato de serviço exposto. O modelo é bem semelhante à uma aplicação JAX-RS, por exemplo, onde se tem uma classe anotada com um @Path da vida, mapeando as entradas do resource, integração com classes de serviço, de repositório e por aí vai.
Fato é que serviços devem ser interpretados como aplicações independentes que visam o conceito de composição. Se elas são vista de forma independente, tem-se uma entrada padrão, que podemos chamar de controller e as demais classes funcionais. Logo, onde tratar as validações torna-se uma escolha arquitetural, sem receita de bolo pronta. Eu, particularmente, gosto de trabalhar recebendo os dados de entrada no controller e repassando-os para o serviço. E lá, injeto serviços complementares pra tratar a requisição e validar os dados. Essa é a MINHA escolha arquitetural, pois acho que isola melhor as responsabilidades de cada componente da aplicação, ou seja, controller trata a entrada e a saida da requisição ao serviço e classes intermediárias de serviço tratam a lógica como um todo ou em pedaços específicos.
Dá uma lida sobre serviços SOA, acho que encaixa como uma luva nesse mundo de microservices e ajuda a sanar algumas dúvidas de patterns para criação de serviços.
Pode validar no “business”, ou seja lá qual for o local responsável pela regra de negócio da funcionalidade. Isso não te impede de usar também o recurso de bean validation.
Não me prendo a essas siglas, mas de qualquer forma você vai ter um objeto java com estrutura de dados que atenda uma ação da funcionalidade.
Seguindo REST todas as partes podem conhecer a estrutura de dados em comum, se este for o caso, não tendo a burocracia do SOAP por exemplo.