Lógica de negócio na camada de dados
Na Synchro devenvolvemos soluções fiscais. E devido a natureza das tarefas que este tipo de software deve desempenhar, temos uma forte dependência do modelo de dados e obviamente dos dados em si. Ou seja, todas as nossas operações são em cima dos dados presentes no banco de dados, alterando seu estado e portanto produzindo o resultado esperado para o negócio.
Há um tempo atrás estudei bastante sobre Clean Architeture (e suas referências) e fez bastante sentido. A partir daí trabalhei com alguns colegas para definir uma arquitetura coerente com os conceitos apresentados pelo Uncle Bob. Nossa arquitetura de referência propõe proteger o código de negócio — que traduz nossa expertise sobre o domínio fiscal em código fonte— do código que existe apenas para fazer interface com os mecanismos externos, ou seja, frameworks e drivers.
Se você leu o post do Bob, você deve imaginar que nosso código de negócio (Business Logic) está no centro da cebola e o banco de dados é um mero detalhe, um side-effect. E tanto faz, para o código de negócio, se existe ou não um banco de dados, ele não conhece nada sobre isso pois a direção da dependência é de fora para dentro. Ou seja, os anéis exteriores conhecem os anéis internos, porém o contrário não é verdadeiro.
Mas como eu disse no inicio, nossas soluções são profundamente baseadas no modelo de dados. Geralmente nos referimos a isso como Data Centric Applications.
A questão é que dado o alto volume de dados com os quais nossas aplicações lidam, temos que nos preocupar em manter um nível aceitável de desempenho. Qualquer deslize na implementação é multiplicado por bilhões de registros e o desempenho vai pro espaço.
Quando trafegamos dados, sempre estamos sacrificando alguns milisegundos e prejudicando o desempenho. Ou seja, quando tiramos os dados do servidor de banco de dados, trafegamos pela rede e levamos para o servidor de aplicação, onde reside o código da lógica de negócio, teremos um desempenho inferior do que se levassemos a lógica de negócio ao encontro dos dados, rodando este código onde os dados residem fisicamente.
Nos dias de hoje, se você disser que a camada de lógica de negócio da sua aplicação é implementada no banco de dados vão te perguntar quantas décadas você esteve preso na Orla Exterior. Nós simplesmente não implementamos mais nada que rode no servidor de banco de dados. Isso é visto como um anti-pattern, uma aplicação mal feita. E nem estou falando de PL/SQL. No Postgres é possível usar javascript e python por exemplo.
Então, porque ao invés de levarmos o código (menor em volume) aos dados, fazemos o contrário, trafegamos grandes volumes de dados ao servidor de aplicação, implicando em um uso extensivo de I/O?
A primeira coisa que me vem a mente quando penso em colocar lógica de negócio no banco de dados é o problema da escalabilidade. Bancos de dados são monolíticos por natureza. Apenas há alguns anos, com o boom de sites como Facebook e Twitter, começamos a pensar em escalabilidade de banco de dados. Já escalabilidade de servidores de aplicação é algo trivial. Colocamos 5o EC2, conectando no mesmo banco de dados e voilá (contanto que sua aplicação seja stateless).
Além disso, quando rodamos em um servidor de aplicação, seja Java, Django, RoR ou Node.js, temos uma arquitetura de software muito mais evoluida. Isso nos trás melhor organização de código e portanto melhor manutenabilidade, suporte a testes automatizados, refactoring e tudo mais relacionado a boas práticas e design.
Mas fico pensando o quão legal seria ter um ambiente de execução que una o melhor dos dois mundos. Algo como um banco de dados que suporte organização de código seguindo uma arquitetura como a Clean Arquitecture proposta por Uncle Bob Martin. Que dê um suporte sólido a teste, onde possamos implementar um código limpo, orientado a objetos ou seguindo paradigma funcional. Que seja projetado pensando em deploy automatizado , escalabilidade e distribuição deste código através do cluster, no nó mais próximo do dado fisico.
Enfim, porquê não levamos toda evolução que tivemos nos ambientes de execução atuais para dentro de um “banco de dados”?
Eu tô maluco?
O que você acha disso? Deixe sua opinião nos comentários!
