Microsserviços: A Maior Armadilha da Arquitetura Moderna | E o Que Domain Driven Design Tem a Ver?

nos últimos anos os microsserviços se tornaram quase que um requisito obrigatório no mercado de tecnologia se você já abriu o Linkedin e procurou por vagas para programador sabe que praticamente a maioria delas exigem conhecimentos em microsserviços mensageria com RT MQ a Cica kubernetes aws servel E por aí vai Esses são os requisitos do momento e com isso a ideia de que microsserviços são solução para todos os problemas se espalhou quase que de forma contagiosa a sensação é de que se você não adotar microsserviços no teu projeto tu vai ficar para trás e o pior você

começa acreditar que todo o sistema precisa ser construído dessa maneira como se essa fosse a única forma da gente construir sistema moderno e escalável e é por isso que no vídeo de hoje eu vou te mostrar Por que você não deve começar um projeto utilizando microsserviços Inclusive eu também vou te mostrar qual é a relação que sut tem diretamente com domain driven design e fora isso eu também vou te mostrar qual é a melhor arquitetura para você iniciar um projeto do zero e que até as maiores empresas de Tecnologia do mundo já estão adotando essa

arquitetura fala pessoal Renato Augusto aqui de novo e dessa vez para te mostrar uma das maiores armadilhas da arquitetura de software moderna que é obsessão por microsserviços muita gente acha que microsserviços são um objetivo e não uma ferramenta que um sistema distribuído cheio de pequenos serviços Independentes automaticamente significa um software moderno escalável e preparado para crescer e essa ideia se espalhou tanto que parece que qualquer projeto precisa nascer assim o que muita gente não sabe é que até as gigantes da tecnologia já começaram a repensar essa abordagem de microsserviços um exemplo disso é a Amazon

que é menos de 2 anos nos divulgou uma notícia dizendo que migrou parte do sistema da Amazon Prime de volta para uma arquitetura monolítica e conseguiu reduzir em mais de 90% os custos com infraestrutura na WS uma menor complexidade sistêmica e muito mais eficiência operacional e antes que você torça o nariz e diga que monolito é coisa ultrapassada Calma que eu não tô falando aqui daquele sistema gigante desorganizado e difícil de manter eu tô falando aqui é de um tipo diferente de monolito que foi projetado para resolver exatamente os problemas que levaram tantas empresas a

adotar microos serviços prematuramente e se você é um aspirante arquiteto de software deve estar se perguntando tá E qual é o caminho que eu deveria seguir nessa história toda antes de eu te responder essa pergunta eu preciso te lembrar primeiro como que funciona uma arquitetura monolítica e como que funciona uma arquitetura baseada em microsserviços entendendo primeiros monolitos a coisa aqui é bem simples pensa no monolito como aquele sistema que centraliza todas as funcionalidades dentro dele mesmo isso significa que tudo roda dentro de um mesmo processo e todas as partes do sistema como cadastro de cliente

processamento de pedido geração de relatório está tudo no mesmo lugar e geralmente o monolito tem apenas um banco de dados para toda a aplicação e um repositório pro código fonte a grande vantagem do bom e velho monolito é que ele é simples da gente desenvolver testar e escalar verticalmente e até horizontalmente com a escala vertical Você pode adicionar mais recursos no servidor como mais memória mais poder de processamento mais armazenamento e otimizar ele para atender uma carga maior de requisições sem precisar dividir a aplicação em vários microsserviços logo de cara já para escalar um monolito

horizontalmente a gente a gente cria réplicas do nosso sistema e coloca essas réplicas debaixo de um load balancer e ele vai se encarregar de receber todas as requisições dos usuários e distribuir essas requisições entre as várias instâncias que a gente criou do nosso sistema agora como Nem tudo são flores as desvantagens dessa abordagem é que se uma parte do sistema precisar de mais recursos do que outra por exemplo imagina que o nosso sistema tá recebendo uma enchurrada de requisições E aí a gente Analisa e descobre que a maioria dessas requisições é relacionada à área de

pagamentos do nosso sistema infelizmente por ser um monolito a gente não consegue escalar só essa área a gente vai ter que escalar o monolito como um todo e isso pode ser bastante ineficiente além de ser um baita desperdício de recurso Além disso geralmente o monolito tradicional ele tem um acoplamento muito forte a nível de código e isso aí pode acabar trazendo problema porque imagina tu mexe numa parte do sistema tu pode acabar afetando outras partes e isso torna o sistema muito mais frágil e difícil de manter a longo prazo e uma outra desvantagem dos monolitos

é que a gente também tem a dificuldade do trabalho em equipe Então imagina uma equipe monstruosa trabalhando numa única base de código no repositório lá no github Imagina 300 PR subindo um por cima do outro isso pode ser extremamente bagunçado e tornar a coisa um verdadeiro caus já numa arquitetura baseada em microsserviços que é o sonho de todo Júnior implementar tem uma abordagem um pouco diferente o sistema ele é dividido em pequenos serviços independentes e que se comunicam entre si via rede ou via mensageria Além disso cada microsserviço ele vai ter o seu próprio banco

de dados seu próprio ciclo de vida e ainda pode ser de desenvolvido em diversas tecnologias diferentes isso aí de cara já traz pra gente a possibilidade de escalar cada microsserviço de forma independente então por exemplo imagina que a gente tem o nosso microsserviço de pagamentos Aquele que tava dando problema lá no monolito e a gente sabe que a maioria das requisições tá chegando é para ele então se a gente já tem um microsserviço de pagamentos a gente vai escalar só esse cara seja verticalmente adicionando mais poder computacional ou seja criando novas réplicas dele então a

gente consegue tratar cada um de forma independente isso é extremamente poderoso outras vantagens que a gente pode ter na arquitetura baseada em microsserviços é que a gente pode ter times separados para cuidar de cada microsserviços o que facilita e muito a especialização de cada time de acordo com o contexto que eles trabalham E além disso a gente ainda pode construir cada microsserviço com linguagens de programação diferente então se o nosso microsserviço lá de pagamentos é um serviço crítico e que precisa de extrema velocidade e poder de processamento a gente pode usar um Rush ou um

golang da vida já nos serviços menores ou que não tem tanta demanda a gente pode usar Frame e linguagens mais focados em produtividad como java com Spring PHP com larv o JavaScript com nes tem o csharp também e por aí vai e tudo isso parece muito bonito e realmente gera aquela sensação de que todo o sistema tinha que nascer assim só que é aí que entram as desvantagens dos microsserviços e o lado sombrio deles que ninguém te conta e aqui vai alguns motivos para você nunca começar o teu projeto com microsserviços o primeiro motivo é

que os microsserviços aumentam a complexidade sistêmica exponencialmente quando você tá começando um projeto teu foco principal tem que ser na entrega de valor e no desenvolvimento rápido de novas funcionalidades com o microsserviço você adiciona uma camada Extra de complexidade desde o primeiro dia de projeto só para você ter noção Você vai precisar de um sistema de comunicação pros teus microsserviços Você vai precisar de ferramentas para montar tuas pipelines de CCD Deploy versionamento Independente de cada microsserviço monitoramento tracing observabilidade log e além de tudo isso cada microsserviço tem o seu próprio banco de dados o que

aumenta muito a complexidade e se tu pensa que acabou tá muito enganado você também vai ter que implementar mecanismos de mensageria com rapit MQ o SQS a pas Cica você vai ter que ter um bom time de devops para gerenciar toda essa infraestrutura Além disso você vai precisar Obrigatoriamente que o teu time domine alguns padrões como cqrs event driven architecture event source event Storm domain driven design e isso tudo é só a ponta do iceberg e é aí que entra o clássico o princípio yne ou seja you a gonna need it que traduzindo seria você

não vai precisar disso já tem vídeo aqui no canal falando sobre isso quando você começa um projeto quando você começa um novo sistema quanta certeza você tem de que esse projeto vai ser útil pro usuário final muita das vezes a melhor maneira de descobrir se uma ideia de software é útil se ela é boa é construir uma versão simplista dela ou seja um MVP o mínimo projeto viável e ver o quão bem ela funciona e durante essa primeira fase de desenvolvimento você precisa precisa dar prioridade total na velocidade para poder começar a receber logo os

feedbacks do teu sistema então o tempo que você tinha que est gastando construindo funcionalidades essenciais do domínio da aplicação você acaba desperdiçando com infraestrutura e com um monte de complexidade desnecessária isso sem contar que em equipes menores geralmente não tem especialistas em arquiteturas distribuídas para lidar com todos esses desafios E aí o que acontece é que muita das vezes o time acaba se perdendo na configuração da infraestrutura antes mesmo de validar o produto n mercado e esse foi só o primeiro motivo o segundo motivo é que microsserviços não é para qualquer software arquitetura de microsserviços

é uma arquitetura extremamente poderosa Porém isso não é para software de padaria nem para software de mercadinho e nem para software de m porte essa arquitetura ela foi criada pra gente escalar não só o sistema mas também os times pensa comigo se você tem um monolito hoje e tem 10 programadores trabalhando nele Qual é a lógica de migrar isso para microsserviços cada microsserviço ele precisa ter um time dedicado para focar nele não é saudável que todos os programadores deem manutenção em todos os microsserviços isso não faz nenhum sentido até porque o programador vai ficar igual

o Pato ele nada anda e voa mas não faz nada direito os times eles precisam ser especialistas naquele serviço ou naquele domínio específico que eles estão trabalhando e é por isso que os microsserviços ajudam a escalar os times também não é só o sistema então A ideia é que quando a tua equipe chegar a dezenas e mais dezenas e até centenas penas de programadores e começar a ter problemas com todo mundo mexendo na mesma base de código Aí sim você começa a pensar em quebrar a tua aplicação em microsserviços porque aí você vai est com

o cenário ideal na mão e com a necessidade então entenda necessidade grave essa palavra necessidade e o terceiro e o principal motivo é a falta de conhecimento de domínio da aplicação quando a gente escolhe direto para microsserviços a chance de dar tudo errado é extremamente alta justamente porque a gente ainda não tem conhecimento do domínio suficiente no começo do projeto o domínio ainda tá sendo descoberto as regras de negócio os processos as entidades tudo isso tá em constante evolução é como construir uma casa sem ter uma planta completa Você pode até começar a levantar as

paredes mas a chance de você ter que derrubar uma parte e refazer de novo é enorme você inevitavelmente vai acabar criando microsserviços que não representam corretamente as responsabilidades do teu sistema para isso ficar um pouco mais fácil Vamos imaginar o seguinte vamos imaginar que você começou a construir um e-commerce no início você imagina que precisa de um microsserviço para produtos Um microsserviço para pedido um microsserviço para cliente mas conforme o negócio vai evoluindo você percebe que a gestão de estoque é crucial e tá completamente ligada aos produtos ou então que promoções afetam tanto produtos quanto

pedidos aí você se vê Obrigado a refaturar todos os microsserviços e mudar a comunicação entre eles Além disso Você ainda vai ter que ajustar os bancos de dados porque cada um tem o seu seu próprio banco de dados e isso vai ser tortuoso pro time é um retrabalho constante poderia ter sido evitado se você tivesse esperado para entender um pouco melhor o domínio da tua aplicação e é exatamente aqui que brilha o domain driven design ou seja desenvolvimento orientado a domínio domain driven design não é uma arquitetura não é uma forma de você colocar as

pastinhas ali do teu projeto em ordem ele é uma abordagem de desenvolvimento de software que coloca o domínio do negócio no centro de tudo ele te ajuda a entender a complexidade do negócio a modelar as entidades as regras de negócio e criar um modelo de domínio rico e expressivo E que esteja alinhado perfeitamente ao negócio com o domain driven design você vai aprender a identificar os bound context que são os contextos delimitados da tua aplicação que basicamente são as áreas do teu negócio com responsabilidades muito bem definidas por exemplo no e-commerce a gente poderia ter

um contexto delimitado para catálogo de produtos outro para processamento de pedidos outro para gestão de clientes e assim por diante C com texto delimitado vai ter o seu próprio modelo de domínio suas próprias regras de negócio e a sua própria linguagem que no DDD a gente chama de linguagem ubico e só depois que a aplicação tiver madura o suficiente chegar num nível que você conseguir bater o olho no código e conseguir identificar cada módulo ou cada bounded context muito bem definido Aí sim você começa a pensar em microsserviços E é exatamente aqui que entra a

solução proposta por Martin Fer chamada de monolit first ou seja monol Lito primeiro a criação desse princípio se deu após duas percepções feitas por Martin Fer que é um dos maiores nomes no mundo da engenharia de softw onde ele diz o seguinte primeiro quase todas as histórias de microsserviços bem-sucedidas começaram com um monolito que ficou muito grande e depois foi quebrado e dividido em microsserviço segundo quase todos os casos em que ouvi falar de um sistema que foi criado do zero como um sistema de microsserviços acabaram tendo sérios problemas e ele ainda complementa dizendo que

foi ao perceber esse padrão que vários os outros arquitetos de software começaram a argumentar que você não deve começar um projeto com microsserviço mesmo se você tiver certeza absoluta de que teu sistema vai ficar grande o suficiente para valer a pena e para ilustrar isso no blog do Martin Fer que eu vou deixar o link na descrição a gente vai encontrar essa imagem que ilustra a seguinte situação quando a gente começa a desenvolver um sistema a gente tem dois caminhos O primeiro é o de cima que se a gente decidir ir direto pros microsserviços a

gente vai encontrar um monte de dragão tacando fogo na gente e isso obviamente ilustra a Extrema complexidade e a dificuldade que a gente vai ter se a gente decidir ir por aqui e essa dificuldade é justamente porque a gente ainda não entende bem os limites do nosso domínio falta ainda conhecimento profundo do negócio E além disso a gente ainda tem toda aquela complexidade a nível de infraestrutura que eu já te mostrei antes sobre os microsserviços então aqui é sem sombra de dúvidas o caminho mais arriscado e mais tortuoso pra gente seguir já no segundo caminho

que é o de baixo a gente escolhe por iniciar o nosso sistema com uma arquitetura monolítica e aqui eu não tô falando de monolito bagunçado aqui eu tô falando da gente desenvolver um monolito modular ou seja um sistema que apesar de ser um bloco único de código é organizado internamente em módulos bem definidos cada um com sua responsabilidade clara e objetiva então o retângulo Preto nessa imagem representa o monolito modular que basicamente é o nosso sistema e Cada pecinha colorida dentro dele representa os módulos desse monolito muito bem definidos ou melhor os bounded context que

traduzindo seriam os contextos delimitados lá do dd dele então por exemplo num com a gente poderia ter um módulo pro catálogo de produtos um módulo para pedidos um módulo para gerenciar o carrinho de compras um módulo para clientes um módulo para pagamentos e por aí vai cada módulo desses teria suas próprias entidades suas próprias regras de negócio seus próprios testes unitários e de integração e poderiam ter até o seu próprio esquema no banco de dados mesmo que eles estivessem compartilhando a mesma conexão para isso tudo ficar um pouco mais simples dá uma olhada nesse repositório

aqui que foi um projeto feito na gringa em csharp para exemplificar um monolito modular repara que quando a gente entra no diretório moduls dentro de src a gente encontra diversos módulos como administration meetings payment que seria o módulo de pagamentos a gente encontra o registration user access agora quando a gente abre cada um deles a gente vê que todos eles TM a mesma estrutura de diretórios com as camadas muito bem definidas como a camada de aplicação então aqui dentro a gente teria os nossos use cases a gente tem também a camada de domínio e aqui

dentro estariam todas as nossas entidades desse módulo aqui em específico a gente tem também a nossa camada de testes então aqui dentro tá os nossos testes de integração nossos testes de unidade isso aqui para você que é curioso é uma mistura de Clean architecture com domain driven design então o DDD ele ajuda a gente a delimitar os nossos contextos a entender né os boundary contact e a Clean architecture ajuda a gente a separar a nossa aplicação em várias camadas como a camada de aplicação camada de domínio camada de infraestrutura E por aí vai então aqui

é que tá o grande segredo da coisa toda quando teu código ou teu monolito chegar nesse nível de maturidade que você consegue bater o olho já conseguir perceber um contexto delimitado um Bound context E por aí vai e tudo muito bem definido aí sim faz sentido você pensar em estrangular o monolito e extrair os módulos para microsserviços e isso levando em conta se realmente tu tiver a necessidade porque na maioria esmagadora dos casos um monolito modular muito bem feito é uma boa alternativa aos microsserviços e é mais do que suficiente na maioria dos cenários assim

a gente corre menos risco aprende mais sobre o negócio e deixa a arquitetura evoluir junto com o nosso conhecimento é muito mais inteligente do que tentar adivinhar tudo de cara e já sair construindo um monte de microsserviços você precisa entender que o monolito é que tem que ser o ponto de partida para depois que você tiver todo um conhecimento de domínio depois que você conseguir bater o olho e conseguir enxergar a forma como você consegue separar a tua aplicação Aí sim você começa a tua Jornada Para microsserviço e para te ajudar nessa jornada que eu

sei que deve ter dado um nó no teu cérebro eu vou deixar o link na descrição dos principais livros sobre o assunto que a gente abordou aqui o primeiro livro é migrando sistemas monolíticos para microsserviços do san Nilma que é assim O livro é um absurdo vai na minha que eu só te boto na boa tu sabe disso o outro livro que eu vou deixar também como recomendação também é do sanila que é mestre jedai em arquitetura é o criando microsserviços segunda edição tem que ser o segunda edição que também é outro livro absurdo e

o principal livro sobre domain driven design que não podde poderia faltar é o domain driven design do Eric Evans que foi aí o precursor do domain driven design a gente até tem outras literaturas sobre DDD mas esse aí o livro azul que a galera fala é a Bíblia do domeno do EV design então não deixa de garantir Teu livro não hein com esses três Aí tu já pode passar os próximos se meses aprendendo sobre DDD e microsserviços do jeito certo hein do jeito certo bom e depois desse quase documentário sobre microsserviços monolito monolito modular eu

acho que esse vídeo já merece teu like né então deixa teu like aí se inscreve no canal se tu não for inscrito e eu te convido a fazer parte do clube de membros aqui do canal com apenas cinco cruzeiros brother cinco cruzeiros tu consegue contribuir e fortalecer o canal para eu continuar trazendo esses conteúdos insanos aqui para você se ficou qualquer dúvida deixa nos comentários abaixo que eu faço maior questão de responder por fim eu vou ficando por aqui um forte abraço para você e nos vemos em breve