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.
