Vou falar hoje com vocês sobre algumas estratégias que na modernização de sistemas legados acaba sendo uma armadilha. Cuidados que a gente tem que tomar com algumas decisões arquiteturais que são extremamente relevantes, que aparecem no meio do caminho e parecem extremamente tentadoras. Parece que vai ser mais rápido, que vai simplificar, mas na verdade são atalhos que acabam levando a caminhos muito mais longos.
Eu quero mostrar exatamente para vocês. Acompanha comigo o seguinte. Imagine o seguinte cenário.
Eu tenho aqui uma aplicação monolítica, então eu tenho um sistema, imagina um sistema grande onde basicamente ele é uma aplicação e um banco de dados. Eu tenho aqui uma série de lógicas dentro desse banco de dados, às vezes procedores pesados, às vezes muita implementação dentro desse banco de dados. Eu já tenho esse essa aplicação monolítica legada com a tecnologia que já tá obsoleta, com dificuldades de integração com outros sistemas, com sistemas de parceiros, não fala os protocolos mais modernos.
Eu tenho problema às vezes de performance dessa aplicação, problemas de lentidão. Às vezes eu tenho disponibilidade por causa disso. Então surge-se a ideia de precisamos modernizar, precisamos fazer uma atualização tecnológica, precisamos fazer um desacoplamento digital, enfim.
estratégias que t o objetivo de renovar esse cenário que a gente tem. Então, o que que surge? Surge a seguinte ideia.
Olha, que tal a gente pegar então e criar uma nova aplicação? Então, essa nova aplicação vai ser uma aplicação feito na tecnologia mais moderna. Perfeito.
E a gente fala assim: "Ah, mas vamos aproveitar o mesmo banco de dados. A gente conecta no mesmo banco de dados. Olha como parece interessante.
Eu vou resolver um problema de integração dessa nova aplicação, porque ela já vai estar conectada na mesma base. Eu consigo já de cara expor pro mundo essa nova aplicação com todos os dados antigos que existem. Parece que eu vou acelerar muito, eu vou resolver um baita de um problema.
Só que o grande cerne de problema aqui dessa decisão se encontra numa palavrinha só. acoplamento. Essa solução, ela traz um acoplamento extremamente forte do que é moderno com o que é legado.
E às vezes a ideia é, ah, inclusive eu quero um modelo de arquitetura mais distribuída, mais segmentada. Então, eu crio outras APIs, outras aplicações aqui também já moderna, com tecnologia nova e faço a mesma coisa. Eu vou criar ela aqui, adiciono ela aqui, uma PI moderna, por exemplo, e essa PI moderna vai consumir diretamente também da minha base legada.
Aqui começa a acontecer vários problemas. O problema de acoplamento começa a ser potencializado. Por quê?
Eu começo a ter um cenário onde eu tenho uma aplicação que ela é ao mesmo tempo distribuída, porque afinal de contas eu não tenho mais só uma aplicação resolvendo o problema. Mas ela não é desacoplada, ou seja, ela tá totalmente dependente de um lugar só. Significa que problemas de performance que existiam com esse banco de dados por causa dessa aplicação vão continuar existindo.
Se essa aplicação monolítica cair, as outras aplicações modernas também vão cair. Se eu fizer qualquer alteração nesse banco de dados aqui, ele vai impactar as outras aplicações também. tem uma série de implicações e no final das contas você passa a ter algo mais complexo que você tinha antes, que era só uma aplicação monolítica.
Esse caminho definitivamente, na maior parte dos casos, ele não faz sentido. Às vezes as pessoas fazem isso como estratégia temporária. É válido, mas tem que tomar um cuidado muito grande, porque a chance disso ir aumentando e às vezes essa estratégia temporária se tornar uma estratégia definitiva é muito grande.
Qual caminho, na verdade, a gente deveria pensar? A primeira coisa é, quando eu tô falando nessa aplicação monolítica, essa é uma aplicação grande que trata de vários assuntos e é interessante a gente fazer uma análise sobre que assuntos são esses. E normalmente a gente usa isso, os bounded contacts, ou seja, quais são os contextos delimitados que estão sendo tratados aqui dentro dessa aplicação que eu posso fazer para segmentar isso.
Então, por exemplo, às vezes existe uma parte dessa aplicação que ela tá cuidando especificamente do financeiro, financeiro contest. Os aspectos do financeiro podem ser estrangulados, ou seja, tirados da aplicação obsoleta e migrados incrementalmente para esse novo contexto. Então, por exemplo, vamos supor que a gente tá falando o seguinte: "Olha, existe uma demanda que eu preciso expor para um determinado parceiro alguns serviços financeiros que precisa ser disponíveis para esse esse parceiro.
" Enfim, então eu crio essa API do financeiro. Aonde que tá o grande mudança conceitual aqui? Esse cara vai pertencer a qual grupo?
Ao grupo do financeiro. Isso aqui, esse grupo financeiro aqui, ele vai ter a API, mas ele também vai ter seu próprio banco de dados. Aqui já tem uma diferença gigantesca.
Por quê? Porque eu tô falando que de fato essa aplicação ou essas aplicações que estão nesse contexto, elas são completamente independentes. Elas são tão independentes que elas podem inclusive ser mantidas por um time separado.
Eu posso ter um time que cuida dessa aplicação aqui e que não sabe nada sobre o outro. Percebe? Só que aí tem um problema, problema meio óbvio que surge.
A pergunta que surge é a seguinte: olha, o financeiro, mesmo que você tenha implementado toda a parte financeira, ele tá aqui. Só que o financeiro ele é afetado pelo contábil, por exemplo, ele é afetado pelo controle de faturamento que não tá aqui, ele é afetado por pelo pelos pela gestão do RH que demite pessoas, isso afeto financeiro, enfim, criando exemplos aqui agora, então eu preciso que esse contexto ele esteja integrado aqui. Como que eu resolvo isso?
O problema é acoplamento. Então eu tenho que ter uma estratégia de integração que tenha baixo acoplamento. Uma das estratégias que a gente costuma utilizar é a aplicação monolítica.
Ela pode produzir eventos que vão ser relevantes pros outros contextos. Então, por exemplo, essa aplicação monolítica aqui, ela poderia tá gerando eventos que são postados num broker de mensageria e esses eventos são consumidos pela PI financeira e mantém- ele atualizado. Por exemplo, olha, entrou um novo contrato.
Esse novo contrato precisa creditar numa conta. Por exemplo, essas alterações, elas vão gerar eventos que vão ser atualizados aqui. Que que a gente não pode fazer de jeito nenhum?
é isso aqui, nem isso aqui que é acoplar os bancos de dados nas duas soluções, porque senão de fato eu começo a criar o problema que a gente tá falando antes. Os contextos, as aplicações, os microsserviços, eles devem ser independentes, completamente independentes. O único ponto de acoplamento deles é a mensagem, mas se é um acoplamento básico, a gente pode percionar a mensagem.
a gente tem várias estratégias para gerenciar esse acoplamento. Assim a gente consegue evitar. Parece que é muito mais complexo, mas não é.
é bastante simples, na verdade. E às vezes o medo de, ah, eu nunca trabalhei com a solução baseada em eventos, talvez eu não tenha experiência com broker de mensageeria, faz a gente ficar com receio e toma decisões que lá na frente vão cobrar um preço gigantesco e que não traz tanto benefício assim de entregar mais rápido, ser mais ágil. Então, ó, cuidado, cuidado com acoplamento na hora de pensar em modernização, senão você pode estar saindo de um sistema monolítico legado para um sistema confuso que tem legado e moderno junto e é tudo uma bagunça.
E se você gostou desse conteúdo, já deixa seu like aqui e compartilha esse vídeo também para chegar em mais gente e para você ser notificado toda vez que tiver conteúdo novo aqui no canal. M.
