Quem nunca colocou regras de negócio dentro de um banco de dados? Isso sempre foi algo extremamente natural e muitas vezes estimulado no desenvolvimento de software, principalmente nos sistemas em "duas camadas", permitindo assim centralização de uma regra entre diferentes aplicações ou partes de uma aplicação e otimizando determinadas chamadas.
Contudo, depois de um tempo você descobre que aquilo que era solução se mostrou uma uma péssima ideia, pois ela cria uma serie de problemas e você se vê com um abacaxi enorme nas mãos.
Um dos problemas gerados e aquele que eu considero como sendo o mais crítico é a fragmentação da lógica de negócios entre a aplicação e o banco.
Essa fragmentação dificulta a evolução do sistema pois prejudica o entendimento das regras de negócio espalhadas entre o banco e a aplicação e também pode gerar uma série de erros em diferentes partes do sistema caso seja necessário modificar uma regra compartilhada devido necessidade de alteração em uma parte específica da aplicação.
A solução normalmente adotada caso seja necessário modificar uma regra e não se consiga mensurar o impacto das alterações é fazer um copy & paste dessa regra e então fazer as alterações necessárias, duplicando o código e fragmentando ainda mais as regras de negocio, o que vai gerar mais problemas devido a duplicação de código.
Porém, hoje em dia essa prática não é mais necessária já que existem diversas soluções e padrões de projeto para o desenvolvimento de aplicações de modo que não seja preciso colocar qualquer regra no banco de dados. Um excelente livro que aborda o tema e propõe soluções é o Padrões de Arquitetura de Aplicações Corporativas do Martin Fowler.
Caso queira saber mais sobre os problemas da implementação das regras de negócio no banco de dados leia esse excelente artigo no blog do Fernando Franzini.
Nenhum comentário:
Postar um comentário