Já se passaram muitos anos desde a década de 90 e ainda assim eu continuo ouvindo e vendo muitas corporações colocando regra de negócio das soluções dentro de um banco de dados. Hoje o cenário de soluções corporativas é outro completamente mais complexo e a arquitetura em duas camadas não oferece características que sustente sua evolução. Resumidamente, soluções construídas em duas camadas não cumprem requisitos como escalabilidade, extensibilidade, manutenibilidade, segurança, perfomance e disponibilidade. Dessa forma, hoje usamos arquitetura n-camadas que é a única que, se bem projetada, pode cumprir todos os requisitos não-funcionais característicos das soluções atuais. Segue um resumo básico dos velhos e já batidos motivos documentados que justificam o não uso de regras dentro de um banco de dados:
1. Acomplamento
Regra dentro do banco de dados viola o princípio SOC, que define que cada pedaço de um sistema precisa estar localizado em um lugar único e exclusivo promovendo isolamento, manutenção, reutilização e futura substituição, sem impacto nas outras partes.
2. Falta de portabilidade
Regras escritas dentro do banco não oferecem portabilidade entre os diferentes produtos concorrentes da mesma filosofia de banco de dados adotado. Na década de 90 já era um transtorno e só tínhamos os famosos SGDB. Hoje, então, a coisa piorou com o surgimento do NoSQL e suas várias opções estruturais.
3. Péssima manutenção e código inflexível
Regras no banco de dados são, na maioria das vezes, escritas usando store procedures (filosofia procedural da década de 60) que são desprovidos de recursos e as diretrizes da OOP como encapsulamento, agregação, composição, associação, herança e polimorfismo e da mesma forma não conseguem usufruir de nenhum tipo de padrões (patterns) arquiteturais, projetos e programação.
4. Know-how especializado
Regras no banco de dados precisam ser manutenidas por profissionais que detenham conhecimento especializado para aquele produto específico e filosofia de banco de dados adotado, sendo difícil eqou caro de encontrar mercado ou de formá-lo internamente.
5. Problemas de performance
Soluções de grande porte, dotadas de um grande e crescente número de acessos simultâneos e com a execução de regras pesadas vão degradando gradativamente a performance da solução, podendo até (que é o acontece na maioria dos casos) derrubar o serviço, uma vez que os banco de dados são desprovidos de devidos gerenciamentos de recursos encontrados normalmente em MIDDLEWARE relacionados com técnicas de otimizações, tunning, comunicação assíncronas, mensageira (MOM), escalabilidade vertical e horizontal apropriadas aplicadas especificamente na execução das regras de negócios.
6. Ausência de recursos
Regras de negócio normalmente englobam o uso de recursos como lógica binária, manipulação de arquivos PDF, DOC, XLS, XML, JSON. Comunicação com sistemas externos como LDAP, SMTP, FTP, Mensageira, SOAP, REST etc. Os SGDB normalmente não possuem API’s disponíveis para estes fins e muitos outros recursos, salvo em casos raros que alguns provedores de SGDB fornece alguma coisa bem limitada e proprietária para tratar um ou outro. A coisa piora por que normalmente não existe abertura para se acrescentar uma API de terceiros para dentro do banco.
Conclusão
Martin Folwer, no livro Patterns of Enterprise Application Architecture – capitulo 8, escreveu:
“Por todas estas questões, muitas pessoas evitam implementar regras de negócio dentro de um banco de dados. Eu tento me alinhar com esta visão, a menos que haja um grande ganho de desempenho a ser obtido – o que, para ser sincero, frequentemente ocorre. Nesse caso, pego um método de negócio da camada de domínio e alegremente o transformo em um procedure dentro de um banco de dados. Faço isso apenas em áreas com claros problemas de desempenho, tratando-o como um abordagem de otimização e não como um principio arquitetural”.
Joshua Bloch, no livro Java Effective, escreveu no item 55 (que eu resumi):
“A história das décadas passadas nos mostram que otimização prematura na verdade é mais propenso a causar danos do que benefícios. O caminho da otimização precoce pode levá-lo a uma solução que ainda não seja rápida, arquiteturalmente ruim e, pior de tudo, inflexível e de difícil evolução. Portanto, não tente criar programas rápidos! Na verdade, foque em criar bons programas, usando todos os conceitos, princípios e abordagem necessários. Se um programa bem arquiteturado não for rápido suficiente, a boa arquitetura já estabelecida permitirá que ele seja facilmente otimizado. Não pense em problemas de desempenho enquanto estiver projetando uma solução. Quando terminar a codificação, avalie seu desempenho. Se ele for suficientemente rápido, tudo estará resolvido. Caso contrário, localize a fonte de gargalo usando uma ferramenta de profile e trabalhe nas partes relevantes. Repita esse processo conforme necessário, avaliando o desempenho após cada alteração até apresentar um tempo satisfatório”.
Acredito que todos estes fatos já fornecem base suficiente para que você tenha condições de fazer a sua tomada de decisão.
Até a próxima!
—–
Artigo de Fernando Franzini, publicado no iMasters.
