Artigos Engenharia de Software Vazamento de regra negócio - Identificação e impactos

Sua regra vazou? Quais Impactos? Como descobrir?

Porque erramos?

Aplicações são construídas de forma estanque, ou seja, cada um constrói um pedaço sem conhecer o todo. Esse tipo de desenvolvimento de aplicações parte de conceitos muito antigos, mas que são utilizados até hoje pela grande massa. Esse tipo de pensamento é o principal responsável por aplicações com problemas em seu Coração, quando falamos em coração nos referimos do Modelo de Domínio. Nenhum modelo pode ser construído ou implementado com um micro conhecimento do sistema, pois afeta diretamente o core da aplicação.

Imaginemos que um desenvolvedor recebe a tarefa de implementar uma parte do sistema que gerencia Fornecedores, se ele não souber de outras regras do sistema que envolva fornecedores como Vendas, Compras, Logística, entre outras, o sistema pode estar comprometido. Isso ocorre, pois ele não tem conhecimento do domínio que envolve fornecedores e sim apenas a funcionalidade pela qual ele está responsável no momento.

Para se resolver isso, devemos aplicar metodologias de desenvolvimento ágil, por exemplo DDD prega a participação de toda equipe a cada levantamento, e que o modelo seja construído por todos em conjunto. Assim ninguém constrói algo sem conhecer o Todo, o que diminui bastante um futuro erro na regra por falta de conhecimento do projeto.

Vamos Continuar errando?

O assunto abordado até momento não possui nada de revolucionário, mas a pergunta que devemos responder é: Sabendo disso, porque continuamos fazendo errado? O maior problema é que dificilmente alguém gosta de sair da posição de conforto para aplicar algo que demanda um esforço extra e um retorno desconhecido. Seguindo esse pensamento chegamos à conclusão que a zona de conforto é um brownfield (figura 1).

Brownfield (Zona de conforto)

Figura 1: Brownfield (Zona de conforto)

Viver em uma zona de conforto dessas não é nenhum pouco interessante, então devemos mudar para conseguirmos conquistar algo melhor, podemos pensar nisso como a Teoria do Caronista. Resumidamente temos duas opções: continuar no Brownfield e viver sempre com todos os problemas conhecidos no desenvolvimento, ou buscar mudanças e ir para o GreenField (Figura 2). Nesse nosso caso mudar é uma aposta que na pior das hipóteses nos manterá inertes mas se conseguirmos teremos bons resultados, não seria a hora de arregaçar as mangas e mudar?

Greenfield, uma paisagem dessas é um prazer olhar

Figura 2: Greenfield, uma paisagem dessas é um prazer olhar

Indo ao Ponto, como identificar um vazamento?

Vira e mexe nos deparamos com desenvolvedores discutindo padrões a serem adotados na validação da regra de negócio, sendo que o grande X da questão é: o que deve ser validado na regra de negócio, e o que é feito na camada de Apresentação?

Existem algumas linhas de raciocínio, por isso não tome esta a que seguiremos como verdade absoluta, essa questão tem um certo ar subjetivo, então cada um irá defender a forma a que mais se adapta. Assim seguiremos pela 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, a checagem no cliente no ajuda a garantir uma boa usabilidade do sistema, e a checagem servidor sendo a "Final Frontier" com o serviço que estamos disponibilizando ao usuário, seja ele uma simples entity service (repositório) ou não.

Martin Fowler, em Padrões de Arquitetura de Aplicações Corporativas (figura 1), prega que "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, embutir 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 um grande problema nas futuras alterações, pois teremos dois ou mais lugares para alterar a mesma coisa.

Listagem 1: Exemplo de Validação que vazou

try
{
	Pessoa pessoa = new Pessoa() { Nome = "Carlos Bueno", Status = 1 };
	if (pessoa.Nome.Length > 30) // ---> essa validacao nao deveria estar na Apresentacao e sim na Regra de negocio
       		throw new Exception("Usuario nao pode possuir mais de 30 carateres");

	DominioPessoa.SalvarPessoa(Pessoa);
}
catch (Exception ex)
{
	Response.Write(ex.Message)
}

O código da listagem 1 é um exemplo de vazamento, pois a validação está sendo feita dentro da apresentação. Imagine se tivermos que fazer outro sistema que grave os dados de pessoas, não teríamos que verificar o tamanho do nome novamente? Essa validação deveria estar dentro da classe responsável por salvar pessoas.

Listagem 2: Exemplo onde não houve vazamento

try
{
	Pessoa pessoa = new Pessoa() { Nome = "Carlos Bueno", Status = 1 };
	DominioPessoa.SalvarPessoa(Pessoa);
}
catch (Exception ex)
{
	Response.Write(ex.Message)
}

Agora na listagem 2, podemos ver nitidamente que não houve vazamento da regra, pois nenhuma validação foi necessária na camada de apresentação, não gerando repetição de código.

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

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

Um sistema com vazamento de regra pode possuir inúmeras falhas de segurança além de em algum momento poder gerar erros com danos incalculáveis.

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), tivermos de 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 além da Interface de Usuário que criamos, uma outra, por exemplo, uma aplicação prompt que acesse nossas regras e caso tenha "que duplicar alguma funcionalidade, é um sinal de que a lógica de domínio vazou para apresentação".

Validações Cliente em aplicações web

Falando de aplicações Web, a checagem cliente seriam validações que não envolvessem acesso ao servidor, como verificar se o usuário esta digitando um número 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.

Até o próximo artigo.