Ouvindo Opiniões

Onde manter as regras de negócio? Uma pergunta interessante, sem resposta definida. Ao manter as regras de negócio na aplicação, temos a vantagem do desenvolvimento ser mais rápido, e mais controlado (ao contrário do que muitos dizem, é mais fácil você ir implementando regras na aplicação, pelo menos é essa minha opinião). Porém, essa velocidade obtida no desenvolvimento se perde quando o sistema tende a se modificar e a ampliar suas barreiras. Por exemplo, você preparou um sistema escolar que está funcionando 100%, porém foi feito para desktop. Agora, seu cliente solicita que sejam construídos alguns módulos para web, como por exemplo, lançamento de notas, consulta de boletim e outros...

Bom, é desnecessário dizer que será necessário recriar todas as regras de negócio na aplicação web.

Outro ponto negativo seria o fato da distribuição do sistema, onde a cada atualização, seria necessária a substituição da aplicação (toda ou partes). Mas para remediar essa situação, ou melhor, dizendo, evitar esse problema, temos algumas saídas, por exemplo, colocando as regras de negócio no Servidor de Aplicação (para o caso de aplicações multicamadas), ou então manter as regras no próprio banco de dados.

Ao se pensar no servidor de aplicação, devemos pensar no reuso das regras. De nada adianta você fazer uso de um servidor de aplicação, usando Delphi se a parte Web é feita em PHP e não consegue aproveitar o que foi feito em delphi. Então, o primeiro problema seria como desenvolver o servidor de aplicação. Vencido esse passo, o restante fica fácil. Temos nesse ponto itens contra tais como o desempenho no desenvolvimento, pois, apesar de separar o desenvolvimento de interface, regras e banco, tudo tem que funcionar como um conjunto, e de forma que, as regras possam ser aproveitadas indiferente da linguagem que cria a aplicação. Como fator positivo, podemos indicar que, para a aplicação funcionar (interface) é indiferente qual banco de dados utilizamos, podendo trocá-lo caso seja necessário. Outro ponto favorável é o fato de aliviar as "dores de cabeça" no momento de distribuir as atualizações, pois se as atualizações forem feitas apenas na camada de regras, é necessária apenas a atualização do(s) servidor(es) de aplicação.

Mas temos ainda uma forma de se elaborar as regras de negócio: mantendo-as no banco de dados! A idéia a princípio parece brilhante! Temos centralizado as regras de negócio, ou seja, tanto faz qual a linguagem utilizarmos, temos as regras mantidas, sem a necessidade de reconstrução e sem o problema de elaborar um servidor de aplicação que converse com várias linguagens.

Outro ponto favorável seria a distribuição da aplicação! Executamos um script do banco e voilá! Está tudo pronto! Mas nem tudo são flores. Manter as regras no banco de dados pode causar de leves "dores de cabeça" a uma insuportável enxaqueca! Isso por que às vezes a aplicação necessita muito do banco de dados, o que faz com que o acesso a ele fique lento! Imagine um sistema que tem módulos web rápidos, interativos, fazendo uso de Ajax, CSS, e outros recursos, com o intuito único de ser veloz e preciso. Em conjunto com essa aplicação web, temos um sistema desktop robusto, grande e que por suas características é bem pesado e possui alguns módulos de execução lenta e pesada. Bem, o desempenho de um afetará o outro com certeza. Apesar dos SGBD's (sistemas gerenciadores de bancos de dados) tentarem ser escaláveis, isso na prática nem sempre ocorre! O mesmo mal-estar pode ser sentido ao se tentar fazer unicamente a alteração no tipo de um campo (de inteiro - integer - para texto - varchar - por exemplo). Por possuir validações, dependências e outros, pode ser que você nem consiga fazer a alteração sem recriar boa parte das regras, o que às vezes é muito inoportuno (principalmente quando o cliente está com pressa). E um outro ponto menos significante, é o fato do seu cliente já possuir a licença de um banco de dados (Oracle, por exemplo), e seu sistema for feito pra outro (DB2, por exemplo). O que fazer? Indicar a concorrência? Estudar todo o banco novamente? Bem, nenhuma das alternativas seria boa coisa.

Como eu disse no início não há uma resposta definida ou certa. Cada caso é um caso. Temos sistemas muito bons que implementam todas as regras na aplicação, outros, em um servidor de aplicação, outros no banco de dados. O que mais importa é como você implementa e projeta seu sistema. Se um sistema é bem definido e bem planejado, sofrerá pouca necessidade de manutenção ou refactory de módulos (reconstrução). O planejamento, aliado do bom sendo, é o melhor amigo no momento do desenvolvimento. Separar corretamente quais regras ficam no banco, quais no servidor de aplicação, quais na aplicação, o local certo de cada regra, o momento certo de aplicar cada forma de desenvolvimento, enfim, tudo isso é que realmente é importante.

Pois bem, planejem bem, para evitar retrabalho, pois como diz o tio Sam... "Time is money!".