Problemas ao usar o banco de dados para regras de negócio

8 de dezembro de 2016 Por Ramon Durães

A evolução da tecnologia trouxe ao mercado novos dispositivos com preços mais acessíveis, que junto a oferta de serviços de internet na rede celular democratizou a inclusão digital e aproximou empresas que passaram a comunicar entre si utilizando a internet e meios relacionados. As aplicações antes limitadas ao ambiente corporativo são cada vez mais expostas externamente permitindo acesso de qualquer lugar e por um número cada vez maior de usuários.

Com essa transição do mercado para o mundo “conectado” surgiu a necessidade de aplicações modernas, conectadas definindo uma nova dinâmica nas aplicações que passaram a ser consumidas não somete pelos usuários locais e sim por milhares de outras pessoas e até dispositivos “IoT”. Essa ruptura conceitual provocou o fim dos modelos tradicionais de desenvolvimento de software orientado a banco de dados que se tornaram conhecidos como “Client/Server”.

O desenvolvimento orientado a banco de dados é tão crítico que uma geração inteira de profissionais foi moldada em pensar primeiro no projeto de banco de dados do que no projeto da aplicação e do negócio em si. Tal fato se agravou ao longo dos anos por alguns motivos. Um deles se originou pela falta de investimento em práticas de desenvolvimento de software e outro por “indução” dos provedores de banco de dados que tentaram a todo custo transformar os seus servidores “elefantes” em serviços de aplicação.

A propagação e até “contaminação” conceitual foi tão grande que até hoje é muito comum encontrar grande parte da inteligência da aplicação injetada dentro do banco de dados comprometendo os negócios atuais, manutenção e evolução. A indústria de tecnologia passou por evoluções e momentos “chaves” na transformação, no entanto as vezes esses “entraves” atravessam gerações até serem resolvidos.

O fato é que o modelo “Client/Server” se foi de vez e é inaceitável projetar uma aplicação / serviços / API / SaaS ou qualquer outro software olhando para uma tabela no banco de dados.

A transformação atual é tão profunda que já não discutimos mais em ir para Web e sim em transformar complementarmente o seu negócio em um serviço digital e conectá-lo na era “API Economy”. Utilizar o banco de dados como repositório de inteligência de negócio compromete 100% a transformação digital e evolução do seu negócio. É deixar de lado todas as estratégias desenvolvidas ao longo dos últimos 20 anos em orientação a objetos, reuso, arquitetura de software, padrões de projetos, DDD (domain driven design) , TDD (Test Driven Development), automação de testes, microservices, Contêineres, DevOps e Cloud.

A eficiência do seu negócio digital é baseada na sua capacidade de responder as demandas com qualidade e agilidade. Ao tentar empurrar o seu modelo de “Client/Server” como uma roupagem de serviços o seu resultado será apenas contribuir para o declínio do seu projeto e do seu negócio. É inviável escalar uma aplicação de grande volume que depende de processamento de negócio no banco de dados. É inviável manter milhões de linhas de código armazenadas no banco de dados.


O projeto das suas tabelas de banco de dados e do seu CRUD (acrônimo de Create, Read, Update e Delete na língua Inglesa) é a parte que você tem que menos se preocupar. Não adianta pensar em tabelas e stored procedures e esquecer do principal que é a inteligência do negócio.

Não vivemos mais na era do eu acho. Um negócio digital tende a tomar proporções gigantescas e uma insistência no desenvolvimento “analógico” de software vai propagar problemas difíceis de serem resolvidos, sem falar no custo operacional em sustentação, continuidade e operação com uma estabilidade custosa ao ponto de inviabilizar.

O entendimento deturpado do banco de dados chegou-se ao ponto de se utilizar o mesmo como serviço de arquivo “File Server”. Você já parou para se perguntar de onde surge essas ideias? Já parou para se perguntar quanto custa processar e armazenar objetos estáticos em um banco de dados comparando com um storage de nuvem? Já se perguntou quanto de processamento desnecessário você está levando ao banco de dados para manipular um objeto estático? Você já se questionou que durante o tempo perdido processando um objeto estático o seu banco de dados poderia estar executando uma operação de leitura e/ou gravação?

O banco de dados é apenas um repositório de dados e nada mais como qualquer outro serviço que esteja conectado a sua aplicação. No mundo dos serviços é necessário iniciar desapegando de todos os paradigmas para conseguir superar os traumas impostos ao longo dos anos. As plataformas de ORM (Mapeamento objeto-relacional) suavizam essa relação de dependência que junto com um projeto estruturado de arquitetura de software coordenam uma experiência de produtividade, performance e fácil manutenção.

O que mais escuto hoje conversando com clientes são dores relacionadas a escalabilidade das aplicações e todas vinculadas ao relacionamento da aplicação com o banco de dados e seu ciclo de vida promiscuo. O modelo tradicional de banco de dados relacional vem sendo contraposto aos cenários tidos como “NoSQL” contribuindo com uma blindagem maior evitando a contaminação com inteligência de negócio.

Toda essa conversa que estamos tendo ao longo desse artigo está relacionada aos traumas “Client/Server” onde sua aplicação vivia plugada no banco de dados com uma relação de dependência desproporcional realizando milhares e milhares de operações completamente desnecessárias. Ao terminar ao sua reflexão abra qualquer das suas aplicações e observe o que comentei.

Nesse momento eu te trago ao mundo real, moderno e orientado ao desenvolvimento de software “digital” lhe tranquilizando que essa relação viciosa e equivocada NÃO existe sendo fruto de um momento que não faz parte da nossa realidade. Tenha o banco de dados como um vizinho e converse com ele o mínimo possível. Quanto menos você visitar com a sua aplicação mais saudável e escalável será o seu projeto.

Para saber mais:
O impacto do banco de dados nas aplicações
Uma nova relação entre desenvolvedores e banco de dados

Até a próxima !!!

Ramon Durães

CEO, 2PC

MVP, Visual Studio

PSM, CSM, LKU

Esse artigo é um oferecimento da 2PC. Entre em contato para modernização de aplicações, Devops, Visual Studio e arquitetura de software.