Validação e Clean Architecture

[matheusdf6]

Bom dia pessoal!

Venho trazer uma discussão envolvendo arquitetura. Estou numa fase de avaliação de débitos técnicos e refactors no meu código, e venho lendo alguns artigos que falam sobre a validação de dados e onde se encaixam dentro da arquitetura limpa. Cheguei nesse comentário feito pelo Uncle Bob e outras discussões de que a validação deve estar na camada de domínio (me corrijam se eu estiver errado). Alguns defendem que cada camada da arquitetura deve ter sua própria validação, e assim por diante.

No meu código, venho utilizando MobX junto a formulários para um comportamento mais reativo mostrando erro durante a digitação e habilitando/desabilitando submissão. Para esse comportamento reativo, a validação está dentro da Store e há regras pra cada input usando reactions do MobX. Por isso me pergunto: como poderia alocar essa validação para camada de domínio sem perder a reatividade? Na verdade, deveria fazer isso? Duplico a validação para de certa forma "consolidar" as regras na camada de domínio?

Queria saber o que vocês tem feito nesse sentido, e quem sabe tirar algumas ideias disso.

[Bwolfs2]

Na minha visão, validacao no Dominio é obrigatória, validacao na tela é opcional.

• Mas porque é obrigatória no Domain? Porque o Domain é o Core da sua aplicacao e ele que garante que as coisas estao indo certas para o servidor ou para as camadas posteriores ( infra, exaternal, data, etc... ), AHHH mas eu to validando na minha tela e nao vai chegar nada errado, agora talvez nao porem caso voce mude sua tela ou caso voce chame o mesmo caso de uso em outro lugar e "Esqueceu de validar" nesse lugar, ai booomm vai chegar coisa errada no seu servidor...
• Pensando em Testes é impressindivel ter testes no seu Domain justamente por ser o Core, ou seja seu Core tem que funcionar direito ou seja tem que ter uma cobertura de Testes boa... E se sua regra de negocio nao ta no Core... O que voce estaria testando?
• Entao eu nao devo testar na minha tela? A tela vai garantir um feedback visual pro usuario isso tem mais relacao a UX do que regra de negocio... Mas sim eu normalmente faço esse double-check.

[matheusdf6]

Valeu pela resposta! E realmente, faz sentido o porquê de estar no domínio. Mas você falou de fazer esse "double-check" na camada de apresentação. Pra esses casos, como tem feito de maneira prática? Tem replicado a regra numa store (ou outro componente de estado)? Tem utilizado a própria classe do UseCase para implementar um método de validação? Utiliza uma "interface" comum que tanta a classe de UseCase quanto a Store utilizam para validação do domínio? Estou pensando como posso fazer essa mudança sem replicar código.

[Anzell]

Permita-me complementar @Bwolfs2

Por regra, o servidor também deve ter como um de seus papéis fundamentais a validação (na camada domain), porque se acontecer de o front encaminhar dados inválidos, ele deve barrar antes de fazer o restante do processamento daquela usecase. Ainda mais quando esse servidor comporta para vários fronts, ou até mesmo quando há endpoints sendo lançados de maneiras maliciosas. Óbviamente, essa validação no back não inibe a importância de ter também no front para evitar chamadas "desnecessárias" (eu particularmente acho tão importante uma validação no back quanto outra no front), e também você pode defender que o front deve ser "burro", ou seja, fazer uma validação qualquer e básica na camada de presenter (view) e deixar o backend se virar com os dados que vão pra lá. Vale ressaltar que já vi casos onde o programador tenha decidido trazer a estratégia de Value-Objects para dentro das Entities para fazer essa validação (acho que isso veio do DDD), nesse caso, os objetos são criados já validados e seguindo seu caso de uso

Vamos supor que o projeto em questão usufrui de algum stateless (Firestore). Se faz então imprescindível uma validação na camada domain para seguir o que a clean arch propõe, você até pode ter essa validação na sua camada de presenter a fim de dar um feedback visual para o usuário, mas no domain tem que ter

[matheusdf6]

Valeu @Anzell pela colaboração!
Quanto a validação, creio que há consenso de que o backend é parte essencial no processo, e a grande questão é no front. Como você mesmo disse, há alguns que tem essa ideia do frontend "burro", mas de fato depende bastante do tipo de projeto.
A questão de validação na Entity não sei serviria pra mim. No meu projeto lido com muito "lixo" no banco vindo de processos legados, então por exemplo, ao recuperar um usuário do servidor ele pode vir sem e-mail, mas ao atualizar perfil ele é obrigatório. Então estou repensando em mover a validação para os UseCases. Se alguém já fez algo nesse sentido, aceitaria uma luz! 😄