Sua Regra de Negócio vazou para camada de Apresentação? Como identificar?

Sua Regra Vazou?

Vira e mexe vejo os desenvolvedores da Accelera (empresa onde trabalho) discutindo entre eles os padrões a serem adotados de validação e o grande X da questão é: o que vai para camada de regra de negócio e o que é feito na camada de Apresentação?

Eu possuo minha linha de raciocínio e não a tomem como verdade absoluta, essa questão tem um ceto ar subjetivo, então cada um irá defender a forma que mais se adapta. Assim sendo eu sou da corrente dos precavidos, ou seja toda regra sem exceção  deve estar presente na camada de regra, por mais simples que seja a validação, mas também devemos fazer algumas das validações no lado cliente, seria um double check, checagem cliente para garantir uma boa usabilidade, e a checagem servidor sendo a "Final Frontier" com o serviço que estamos disponibilizando ao usuário  seja ele uma simples entitie service (repositório) ou não.

Todo vazamento traz grandes impactos. Cuide sempre para que não ocorra.

Nesse sentido Matin Fowler diz: "Normalmente, as pessoas escreviam essa lógica no cliente, mas isso era desajeitado e, normalmente, feito embutindo-se a lógica diretamente nas telas da interface com o usuário  A Medida que a lógica se tornava mais complexa ficava muito difícil trabalhar com este código. Além disso, embuti lógica nas telas facilitava a duplicação de código, o que significava que alterações simples resultavam em buscas de código semelhante em muitas telas", fica nítido seguindo o raciocínio de Fowler que colocar regra na UI (User Interface) causa duplicação de código gerando m grande problema nas futuras alterações, pois teremos 2 ou mais lugares para alterar.

Seguindo O pensamento de Martin, podemos visualizar que se ao criamos uma UI que utilize a camada de regra e quando viermos a utilizar outra interface de acesso a regra (timer job, serviço, uma outra UI) caso tenhamos que repetir algum código pode ter certeza que seu código da regra de negocio vazou para Interface de Usuário, pois essa duplicação cheira bem mal. No livro Padrões de Arquitetura de Aplicações Corporativas, de Martin Fowler, ele diz para imaginarmos alem da Interface de Usuario que criamos uma outra, por exemplo uma aplicação prompt que acesse nossas regas e caso tenha "que duplicar alguma funcionalidade, é um sinal de que a lógica de domínio vazou para apresentação".

Validações Cliente

Falando de aplicações Web a checagem cliente seria validações que não envolvessem acesso ao servidor, como verificar se o usuário esta digitando um numero inteiro, fazer as devidas formatações das entradas de dados, coisas desse tipo, um acesso ao banco com cálculos ou outra regras seriam exclusivo da camada de domínio da aplicação.