Aula 2 - Arquitetura de software: Reduza 80% da complexidade em 3 passos

[Música] Olá tudo bem meu nome é Wesley e seja muito bem-vindo ao segundo vídeo da semana do arquiteto full Psycho se você ainda não assistiu o vídeo um volta lá para depois assistir esse vídeo aqui se você assistiu o vídeo anterior a gente já começou a nossa jornada falando sobre arqu ura de solução explicando o papel do arquiteto e porque mesmo quem é apenas um desenvolvedor precisa entender de arquitetura também a gente explorou um estudo de caso prático sobre uma bola inteligente de vôlei onde Vimos a importância de uma boa arquitetura para resolver problemas complexos

de forma eficiente hoje o nosso foco vai ser um pouco diferente a gente vai falar sobre arquitetura de software eu quero te mostrar como que você pode reduzir em até 80% da complexidade no desenvolvimento de uma aplicação mantendo uma arquitetura sólida sustentável e sem cair naquele problema do Over Engineering essa abordagem Ela é conhecida como Middle Alt ela vai ajudar a gente equilibrar a parte de flexibilidade simplicidade que vai ser totalmente necessária para que esse software ele cresça ao longo dos anos de uma forma bem saudável mas antes de mergulhar nos detalhes eu quero falar

brevemente sobre microsserviços que é um dos Tópicos mais discutidos nos últimos anos talvez você já tenha lido aquele artigo famoso do Martin Fer chamado monolit per onde ele recomenda sempre a gente começar o desenvolvimento como um sistema monolítico e só depois pensar em quebrar isso em microsserviço eu entendo muito bem esse ponto de vista mas com base na minha experiência há muitos e muitos casos onde começar já diretamente utilizando microsserviços desde o início ali pode ser a escolha mais inteligente a gente vai falar sobre os mitos e verdades sobre os microsserviços e como fazer essa

escolha de forma muito mais consciente alinhada ao projeto ao mercado as suas restrições de negócio e também em relação à sua empresa e o seu time um outro ponto crucial é que a gente a gente também vai discutir hoje o conceito de acoplamento muita gente já ouviu falar que o software acoplado é algo realmente ruim mas será que isso realmente é verdade eu vou te explicar os principais conceitos de acoplamento e vou também tentar quebrar aí alguns mitos e mostrar como que o acoplamento ele é importante pra nossa aplicação Inclusive a gente vai falar sobre

acoplamento aferente e eferente tá e como que eles podem IMPA que tá diretamente aí na escalabilidade na manutenção na sustentabilidade do seu software ao longo dos anos a questão aqui não é simplesmente evitar o acoplamento a Qualquer Custo mas entender onde ele é realmente necessário e como que a gente pode gerenciar isso de maneira saudável Além disso eu vou compartilhar com você as cinco leis fundamentais que todo desenvolvedor e arquiteto precisa conhecer para garantir que o seu software ele dure por muitos anos se mantendo flexível e adaptável esses princípios eles são essenciais para evitar retrabalho

e garantir que o sistema ele consiga crescer de maneira sustentável agora falando em crescimento eu vou te mostrar como que isso se aplica na prática com um Case Real em 2012 eu fiz o primeiro comite do sistema que hoje atende a full cycle ele começou como monolite mas com o passar do tempo ele foi sendo quebrado em microsserviços de forma bem estratégica permitindo que a fulls pudesse ser expandida rapidamente hoje esse sistema ele gerencia desde clientes b2b e b2c até integrações com o nosso CRM gerenciamento de toda a faculdade full cycle o acompanhamento de alunos

eventos cobranças de notas fiscais gerenciamento de vídeos com DRM transcoding e muito mais esse exemplo ele vai te mostrar como que é possível evoluir de uma forma simples e eficiente mantendo a arquitetura saudável desde o início então no vídeo de hoje o que você vai aprender é como que você vai construir uma arquitetura sólida eficiente e preparada pro crescimento enquanto você Evita o excesso de complexidade no seu software a gente vai explorar isso com bastante detalhe e alguns exemplos práticos Beleza então bora a pra tela do meu [Música] computador bom pessoal agora aqui na tela

do meu computador chegou a hora da gente falar um pouco sobre a arquitetura de software e nós temos bastante coisa para ver na aula de hoje tá só para você ter uma ideia Olha o que que a gente vai percorrer aqui ó a gente tem muita coisa que a gente vai percorrer desde microsserviços leis est estruturas do próprio sistema e o ecossistema da full cycle a sistemas e problemas que nós tivemos aqui ao trabalhar com a intranet de uma grande empresa então assim tem conteúdo aqui a d de rodo então fica comigo até o final

desse vídeo porque vai ter bastante coisa para você aprender hoje beleza mas tudo que eu tô falando aqui de forma geral pessoal Ah tem a ver com arquitetura de software agora tem um ponto importante que eu preciso que você se ligue tá Ah no vídeo anterior a gente falou muito sobre arquitetura de solução né a arquitetura de solução ela consegue ligar as pontas ela consegue encaixar o pedaços das coisas pra gente ver todo um determinado ecossistema tá já a arquitetura de software ela é uma disciplina tá da engenharia de software ela tá ligado a o

ao processo de desenvolvimento tá então quando a gente tá falando em arquitetura de software de forma geral isso afeta a gente diretamente né na estrutura dos times tá Por que que eu tô dizendo isso quando você vai criar um software nesse momento a gente já tá um pouco mais em baixo nível do que a gente estava na arquitetura de solução tá hoje inclusive eu vou falar um pouco de como que funciona a estrutura aqui da full cych e você vai ter uma visão de uma arquitetura de solução mas ainda assim a gente vai falar sobre

arquitetura de software então não tem essa Preto no Branco a arquitetura de software arquitetura de solução ela tem uma área um overlapping onde as duas coisas acabam se ligando e por conta disso quando a gente vai definir a arquitetura de um software quando a gente começa a trabalhar com arquitetura de software a gente tá falando no processo de desenvolvimento na estrutura dos times dos componentes que o nosso software ele vai ter e esse componente pode ser um componente interno dentro do mesmo software ou eventualmente é um componente externo de uma integração tá ah como que

funciona a estruturação desses componentes ou seja como que a gente consegue entender o nosso software ver quais são esses componentes como que a gente deixa eventualmente esses componentes mais intercambiáveis tá e uma coisa importante também né existe uma lei famosa que é a lei de conway né Melvin conway O que normalmente ele fala nessa lei é que normalmente tá o software de uma empresa ele é desenvolvido né baseado na estrutura organizacional da empresa então a empresa ela vai dizer muito de como que você vai estruturar o seu software você querendo ou não né imagina que

na sua empresa na área de desenvolvimento você tem um Web Designer você tem um programador backend um dba Como que você acha que vai sair a sua aplicação vai ter uma ui vai tá vai ter um sistema e provavelmente um banco de dados que vai est organizado com esse sistema né Se você tiver muito Muitas outras estruturas dentro da empresa e departamentos dessas empresas e profissionais entendendo de domínios diferentes provavelmente a estrutura desse software Iria mudar bastante tá desde a área de produto desde a área do cliente final desde a área das pessoas que testam

o seu software então o seu software ele é totalmente mutável e ele é totalmente a parte do ambiente em que ele vive tá então por isso que quando você vai criar arquitetura de um software você tá ind na empresa a não significa que quando você tiver na empresa B você vai poder replicar o que você faz porque o contexto é diferente e eu acho que esse é um dos maiores erros tá que nós profissionais de movimento a gente tem né a gente quer fazer aquela história de One size Fits All ou seja o que eu

faço aqui serve para qualquer outro lugar e não funciona tanto por questões técnicas culturais maturidade do time orçamento restrições e tudo mais legal agora quando a gente ainda tá falando em arquitetura de software a gente tá falando que ela é uma relação entre os objetivos de negócio as suas restrições com os seus componentes a serem criados e as suas responsabilidades visando a evolução do software então Toda vez que você vai arquitetar um software no final do dia você tá pensando no usuário final você tá pensando em como que isso vai resolver o meu problema de

negócio e o principal né não existe dinheiro infinito não existe tempo infinito né o produto tem um tempo certo para ir pro mercado então se você não entender as restrições que a empresa tem naquele momento não adianta você projetar o maior software do mundo se ele vai demorar 2 anos para sair ou se ele vai est mais sair duas vezes o preço do que tava sendo estimado então não adianta você tem que entender Quais são as restrições da empresa quais são os componentes que vão compor esse software tá Quais são as suas responsabilidades de cada

componente e como que isso vai gerar de impacto ao longo prazo na empresa legal então o processo de arquitetar um software ele estabelece que o que tá sendo desenvolvido faça parte de um conjunto maior Tá então vamos imaginar sempre a gente tá num ecossistema esse ecossistema ele possui diversos softwares ele possui diversas coisas que podem ter sido feitas internamente como externamente na empresa eu vou mostrar isso para vocês daqui a pouco né mas ao mesmo tempo tá Ah quando você tá arquitetando um software em específico né aquele seu software ele vai afetar um ecosistema como

um todo então ele faz parte sempre de um conjunto maior mas não é porque ele faz parte de um conjunto maior que ele simplesmente pode ser feito de qualquer forma porque existem softwares que eles são Core do sistema Você já imaginou a Netflix sem o serviço de playback de de filmes Você já imaginou a Amazon sem carrinho de compras Então comece a perceber que existem softwares que fazem parte do Core domain da empresa né do domínio principal do negócio a gente tem só softwares auxiliares que ajudam esse Core domain funcionar e a gente tem softwares

mais genéricos que normalmente podem ser softwares que a gente contrata de terceiros inclusive que são coisas mais substituíveis tá então quando a gente começa a olhar pra arquitetura de software dessa forma a gente começa a pensar Qual que é o papel do arquiteto e aqui novamente eu venho com a programação com a provocação não necessariamente na empresa que você tá trabalha tem um arquiteto de software mas sem dúvidas tudo que está sendo desenvolvido na sua empresa tem um arquitetura mesmo que você não tenha definido essa arquitetura ela existe pode ser uma arquitetura muito ruim inclusive

mas ela não deixa de existir tá então o papel do arquiteto no final do dia é transformar os requisitos de negócio em padrões arquiteturais né eu tenho que eu tenho um problema a E como que eu consigo estruturar esse problema aqui para ele ser resolvido né como que eu consigo entender o time que eu tenho hoje para que saber que esse time tem capacidade né Tem ferramenta tem recurso tem infraestrutura para conseguir fazer da forma como eu tô pensando e também eu preciso falar com os experts de domínio ou seja as pessoas que vão usar

o software que entendem o que o software faz tá outra coisa eu preciso entender profundamente conceitos e modelos arquitetur naturais Apesar de eu ter dito no início que você nunca replica a arquitetura de um software de uma empresa para uma outra empresa mas obviamente existem padrões e quanto mais padrões Você conhece mais repertório você tem para conseguir ligar li ligar os pontos ao longo da sua jornada dentro de uma compania tá Outra coisa o arquiteto de software tá ou a pessoa responsável por arquitetar muitas vezes é um Leide galera tá Ah ele auxilia muito na

tomada de decisões no momento de crise tá tendo um problema muito grave a gente precisa resolver isso rápido a gente precisa tomar uma decisão e essa decisão ela pode impactar a curto prazo mas essa decisão a curto prazo pode ferrar a coisa lá no longo prazo como que a gente consegue dosar isso então normalmente o arquiteto de software ele ajuda nisso e ele renforçateur [Música] inclusive que fazem muito code review para garantir que os padrões que foram definidos inclusive para aquele projeto estão sendo seguidos tá então observação aqui para você há empresas hoje que não

possuem mais cargo de arquiteto de software isso não significa que o software que você faz não tem uma arquitetura e se você é um desenvolvedor que tá à frente de um projeto ou tá ativamente desenvolvendo esse projeto você é responsável ou corresponsável por essa arquitetura para fazer com que o software dure por muito tempo legal agora a gente tem um ponto aqui que é um ponto meio tricky é um é uma não digo uma pegadinha mas eu não digo que seja algo meio que unânime tá Ah e aqui eu vou dar a minha visão provavelmente

se você falar com muitas outras pessoas ah elas podem ter respostas diferentes para isso tá a a pergunta aqui de de de muita discussão aqui é o seguinte qual Qual que é a diferença de arquitetura de software e design de software né pessoal eu passei um tempo fazendo uma mentoria com o uncle Bob tá então eu participei de um grupo fechado do uncle Bob Ah e na real quando ele começou a falar em arquitetura de software e tudo mais a minha primeira pergunta para ele que eu fiz foi Qual a diferença entre arquitetura e design

de software e naquele momento eu percebi o uncle Bob na numa situação meio de saia justa ao ponto dele dizer arquitetura de software e design de software é quase que a mesma coisa porque eles andam juntos tá E eles ajudam tomar decisão simultaneamente na hora que você vai desenvolver o seu software então não dá para falar de uma coisa sem a outra tá ele falou bem assim para mim mas no final das contas por que que eu tô dizendo isso ele não falou especificamente arquitetura de software é isso design de software é isso E essas

são as suas relações Eu também já falei com muitas pessoas sobre esse assunto e normalmente né Tem pessoas que dão diversas respostas minha opinião pessoal com a experiência que eu tenho e novamente pessoal eu não sou o rei da Verdade você pode ter a sua opinião em relação a isso na minha opinião é que a arquitetura de software ela tem um um escopo mais global ou de de alto nível sobre o software e os seus componentes e as suas restrições o design de software ele tem um escopo um pouco mais local eu vou tentar exemplificar

isso tá como se a gente tivesse construindo uma casa vamos imaginar que na hora de eu arquitetar uma casa eu vou falar que ah na parede da frente da cozinha eu vou precisar ter duas tomadas E essas tomadas elas precisam estar ligadas para fazer com que o micro-ondas funcione assim assim assado ali vai ser o local da tomada tá então na hora que um arquiteto né ele vai fazer o plano executivo dele né Para que sei lá o os engenheiros o o pedreiro lá vá colocar as tomadas ele consiga seguir esse manual né então perceba

que ele tá ali en forçando o que ele quer Qual o componente que ele quer ah o buraco que ele quer ali para botar na tomada o motivo por porque aquilo tem que estar ali e e as direções de como aquelas coisas estão colocadas legal bom o pedreiro o que que ele vai fazer naquele momento ele vai pegar a caixinha ele vai ligar os fios ele vai usar um parafuso ele vai usar uma chave de fenda ele vai organizar vai botar a tampinha e vai botar a a tomada diferente agora se você perceber o arquiteto

naquele momento ele não tá necessariamente nesse exemplo que eu tô colocando preocupado qual é a chave de fenda que ele vai aparafusar Qual é o parafuso que ele vai utilizar né se a caixinha ela vai ser enfiada mais para dentro ou mais para fora esse nível de microd detalhe tá normalmente é uma decisão muito maior de design quando eu tô falando de software porque a arquitetura muitas vezes ela vai fazer o queê para você ela vai falar Vocês precisam desses componentes você precisa fazer isso comunicando você precisa desacoplar esses pedaços você consegue juntar esses componentes

pra gente ter um caso de uso funcionando e tudo mais mas na hora de eu programar em si tá vão ter decisões ali que na minha opinião são muito de design por exemplo Ah eu preciso trabalhar com o design pattern de Ah não tô dizendo que design software é design pattern tá galera só para vocês saberem Mas o que eu tô querendo dizer é qual o pattern que eu vou utilizar para resolver esse problema né Qual é o tipo de algoritmo que eu vou utilizar para conseguir mais velocidade como que eu vou organizar o meu

mecanismo de persistência para facilitar a minha manutenção ao longo do tempo então você consegue perceber que quando a gente cai mais no micro né ah olha como que eu vou fazer o graceful shutdown do do meu software para que ele barre as requisições que ele tá recebendo na hora que ele receba ali um sinal de termination por exemplo se você perceber tá o arquiteto de software ele vai definir os componentes agora esses níveis de detalhe Na minha opinião Eles são muito mais focados na área de design de software é como que eu vou modelar coisa

para ela funcionar é muito mais mão no código e organização do código manter o código funcionando até mesmo a forma de como que você estrutura os seus tests faz parte do Design de software Então essa é a minha visão tá galera a arquitetura de software ela tem um escopo mais global e de alto nível não que por exemplo eu fale eu preciso de um Cash tá e o cara do Design vai falar é o redis não não normalmente o arquiteto fala a gente vai utilizar o redis aqui nesse momento tá a gente vai utilizar nesse

formato Porque a gente já preveu que em algum momento se ele desligar a gente vai guardar os arquivos e não vai ficar só em memória então você obviamente cria um componente De Cash que a gente possa trocar no futuro caso você queira mas inicialmente trabalho com essa ah com esse ponto tá então entenda que eu setei que existe um componente De Cash eu até falei qual o a o software que a gente vai utilizar mas eu não defini como que vai ser a interface e esses detalhes esses detalhes Na minha opinião tem muito mais a

ver com design de software ou seja todas as ações que eu faço de arquitetura vão vão se refletir na área de design mas não necessariamente as minhas decisões de design vão refletir na parte de arquitetura Ok ah outros Pontos importantes agora que eu quero trazer aqui e foi inclusive uma das promessas que eu dei para você né no vídeo de introdução é sobre como que eu consigo resolver 80% dos meus problemas na velocidade de entrega inicial do meu software tá pessoal seguinte tá toda vez que a gente vai criar um software e a gente sabe

que esse software ele vai crescer ele fazesse software faz parte de uma grande organização a gente sempre tá numa saia justa por que que eu tô dizendo isso porque a gente tem pressa de entregar para conseguir né gerar valor pro usuário na forma mais rápida possível mas ao mesmo tempo o que que a gente precisa a gente precisa criar essa estrutura esses componentes essa arquitetura da forma mais sólida possível para que esse software dure longos anos o grande ponto é que na maioria das vezes né esses dois pesos né Essas duas necessidades elas são quase

que antagônicas porque se eu entrego software muito rápido de qualquer forma no início provavelmente no futuro esse software vai ficar insustentável por outro lado se eu forço muito a barra na arquitetura de definição desse software provavelmente eu vou demorar mais valor para entregar pro usuário tá então existe uma técnica tá que é chamada de Middle out tá o qual que a ideia do Middle out a ideia do Middle out é conseguir flexibilizar a forma de como que você vai arquitetar seu software Como assim se você perceber galera todo software ele tem três coisas em comum

tá ele tem diversos componentes e tudo mais mas ele sempre tem aquela parte repetitiva tá eu tô colocando crudes barra asterisco porque pode ser um monte de coisa aí no meio dessa história tá galera eu sei que no final do dia um crud ao longo do tempo ele não vai ser mais um crud ele vai ter regras de domínio ele vai ter regras de validação ele vai emitir eventos e etc né então assim sonhar que um crude é apenas um crude ele não existe crud em sistema grande né ao longo do do tempo ele deixa

de existir e quando eu falo que ele deixa de existir é o famoso criar deletar retrieve etc por quê Porque n nas grandes aplicações apenas isso não gera valor pra empresa em relação a regras de negócio tá então quando eu falo que crude e não existe em grande sistemas é porque raramente numa operação de Create você apenas vai criar numa operação de busca você apenas vai buscar numa operação de deleção você vai apenas deletar um software grande uma ação reflete milhões de coisas e por conta disso que eu digo que crud não existe o crud

convencional que a gente conhece não existem grandes sistemas porém Normalmente quando a gente tá iniciando em diversos sistemas mesmo que eles são grandes em muitos momentos a gente tem um monte desses crud zões que naquele momento eu não tenho tantas regras específicas e que são coisas tão simples de se entregar que o que que eu posso fazer eu posso fazer ele da forma mais simples possível eu não vou criar uma arquitetura rebuscada eu vou fazer de uma forma que eu já consiga fazer o Deploy e o usuário já comece a fazer os cadastros dele o

usuário já consiga buscar o usuário já consiga fazer algumas coisas que podem ajudar no dia a dia tá Pensa em um RP cadastro de fornecedor Poxa n né ainda não tem regra mas tem coisa que já dá para você ir utilizando da forma mais simples agora já pensou se eu tenho que demorar um 2 meses para definir a estrutura inteira da arquitetura do meu sistema para eu entregar um crude galera não faz sentido entende então o que que normalmente a gente faz a gente cria arquiteturas simples tá sem nada de ser rebuscado nas partes mais

variáveis do sistema partes que ao longo do tempo elas vão ser mudadas mas que nesse momento não tem aquela regra pesada de negócio essa parte você faz da forma mais simples possível você usa o seu Framework bonitão você faz ali tudo que você pode fazer da forma mais simples possível porém o que que acontece existe aquela parte que é crítica paraa aplicação né sei lá fazer um depósito num conta bancária fazer um pix Cara isso aí é crítico eu não vou fazer isso aí né ah dentro de um Controller entende essa parte tá que normalmente

é o meio da aplicação é o miolo é a parte onde a aplicação mais grita para gerar valor essa parte você vai gastar tempo para fazer essa parte você vai pensar muito bem para que essa estrutura ela vai ser sólida tá e para que que isso ajuda porque essa parte ela sendo sólida a desde o início você vai perceber que essa parte ela se torna o coração do sistema e quando você tem o coração do sistema adivinha só galera o coração do sistema é a parte mais estável da aplicação o que que isso significa quanto

mais enraizado no coração da sua aplicação tá raramente esses regras vão ficar mudando vou dar um exemplo um sistema de contac corrente galera devem ter milhares de nuances nisso mas com certeza tem um Core ali que deve estar impregnado faz muito tempo e que não tem o porquê dessa parada mudar porque essa parada é débito crédito Tô dando um chute eu não entendo nada de sistemas bancários tá imagina lá a a net flix para dar um Play num vídeo ou como que o vídeo tá sendo armazenado cara provavelmente essa área é tão estável porque esse

negócio já tá tanto tempo lá que se um dia eles quiserem mudar eles vão ter que criar um projeto à parte para conseguir reescrever algo tão importante então normalmente o coração da aplicação é a área mais estável e se ela era a área mais estável é a área que você faz da melhor forma possível as pontas da aplicação são áreas mais inst e como elas são instáveis no início você pode fazer ela muito mais simples e conforme ela vá aumentando essa complexidade você pode tomar duas decisões uma reescrever completamente essa parte se ela é simples

se ela pequena e você fez de uma forma simples é rapidamente fácil você conseguir reescrever né ou você consegue melhorar essa parte até com que ela consiga fazer parte da arquitetura mais Sida que você criou tá o ponto de eu falar disso aqui para vocês é o seguinte galera é uma provocação Quais são as partes do seu sistema que merecem ter a parte mais rebuscada de arquitetura para garantir a componentização para garantir a facilidade de novas features e etc e quais são aquelas partes do sistema que você gastou o mesmo trabalho para fazer isso do

que o Core da aplicação Às vezes a a complexidade que a gente faz para fazer um crude tá sendo exatamente a mesma complexidade de você fazer o coração da sua aplicação Você acha que tem cabimento isso então essa aí é um ponto de reflexão você vai perceber que você vai começar a conseguir entregar software mais rápido depois disso faça os seus testes ok dito isso galera a gente tem bastante coisa para falar tá e tem algumas coisas que eu gostaria de falar aqui antes para você antes de a gente ir para alguns cases e e

fatos e Skills que você vai tendo ao longo do tempo tá uma das coisas que eu queria falar aqui para vocês tá é sobre um artigo bem famoso tá do Martin Fer chamado de monoli first tá o Martin Fer é um cara que eu acredito que todo mundo né na área de desenvolvimento que conhece admira toda a parte de padronização toda a parte de livros artigos o cara assim ele não é fácil encontrar caras como ele no nosso mundo tá agora a gente tem que tomar cuidado com uma coisa galera tá a gente tem que

pensar sempre em duas coisas uma coisa é tempestividade o que que é tempestividade qual foi o momento que Martin Fer falou alguma coisa segunda coisa que a gente tem que pensar contexto Ok por que que eu tô diz isso hoje em dia né esse mundo de microsserviços ele já se consolidou virou Hype por muito tempo tem a gente falava bem Tem gente que falava mal e etc mas no final do dia todo mundo hoje em dia trabalha com microsserviço se você não trabalha talvez você não tenha ou não tenha trabalhado numa empresa muito grande ou

a sua empresa Ah não tem tantos sistemas e não necessita disso tá mas de forma em via de regra hoje em dia trabalhar com microsserviços é algo bem importante o Martin Fer num artigo que ele fez tá ele fala que na visão dele tá Ah você sempre deve iniciar um seu sistema utilizando um sistema monolítico ou seja um sistema que tudo tá dentro dele tá tá tudo contido em um único sistema ok e depois que esse sistema ele ganha uma maturidade né Você pode quebrá-los Em microsserviço inclusive o Martin follower ele tem inclusive um artigo

apenas especific and explicando sobre a história de microsserviço tá E galera eu concordo com ele tá Ah eu concordo com ele no no aspecto de que em 3 de junho de 2015 a gente tá falando quase 10 anos atrás tá a gente não tinha um monte de microsserviço a maioria dos sistemas que a gente trabalhava ali eram monolíticos ou se não eram monolíticos eram monolitos distribuidos ou seja um sistema monolítico que falava com o outro usando soap Ah não interessa a forma ou utilizando Aqueles barramentos né de enterprise service bus e coisas desse tipo tá

mas pensa bem até hoje eu ouço falar galera primeiro monolito e tem o artigo do Martin Fer então primeira coisa que você tem que entender é faz 9 anos que o Martin Fer escreveu esse artigo segundo ponto hoje em dia né de forma geral grandes desenvolvedores e grandes programadores e quando eu digo grandes pessoas que já trabalharam bastante em diversos sistemas já sabem as pegadinhas de microsserviço e monolito aonde D grande besteira quando você já utiliza um um microsserviço A gente já aprendeu bastante com isso a gente já errou muito isso então Já tem muitas

coisas que são Claras que você já vê que o negócio vai dar problema logo de cara tá Por que que eu tô fazendo esse ensejo aqui nesse momento galera porque eu não acho que você deve sempre começar pelo um monolito muitas vezes você pode sim começar a trabalhando com microsserviços tá e não achar que o Martin Fer ele vai puxar o seu pé à noite na hora que você for dormir tá mas novamente é questão de contexto Então o que eu coloquei aqui tá galera quando nós não devemos começar com microsserviços minha opinião quando você

tem baixo conhecimento sobre o domínio se você não sabe direito que o software vai fazer ou que esse domínio ele pode mudar facilmente Você não vai sair criando um monte de microsserviço porque cara daqui um mês a empresa pode ter mudado o mercado pode ter mudado a forma de atender os clientes e simplesmente você vai jogar um monte de código fora ou você vai começar a criar um Frankenstein tá então então se não há estabilidade no modelo de negócio se não há estabilidade no modelo de domínio cara começar com microsserviço é um tiro no pé

tá Ah Outro ponto imaturidade da equipe tá existem muitas equipes que são imaturas para trabalhar com microsserviços e o que isso significa ou nunca trabalharam tá ou não conseguem entender alguns princípios de compon ização princípios de reusabilidade e comunicação entre sistemas uma das coisas que você mais tem que bater o pé na hora de aprender a mexer com microsserviços é entender Protocolos de comunicação entender como que as coisas conversam a grande sacada dos microsserviços é entender tá como que esses caras se comunicam quando você tem uma equipe imatura e quando eu falo imatura galera não

tô falando no sentido eh pejorativo mas uma equipe que nunca trabalhou com microsserviços que nunca não não entende conceitos de resiliência não entende conceitos de mensageria né não sabe o que que é um circuit Breaker Ah uma política de retry uma política de timeout quando você tem esses tipos de situação Realmente é muito complexo é melhor você começar criando um sistema monolítico tá outra coisa tem muita empresa que apanha muito para botar fazer o Deploy ainda né então em imagina que você tem 10 microsserviços você vai ter que ter 10 pipelines de ca CD você

vai ter que ter 10 processos de teste você vai ter que 10 ah formas de gerar o seu contêiner você vai ter que fazer o Deploy de 10 aplicações você vai ter que se organizar sei lá num kubernetes Então quando você começa a cair nesse tipo de situação e os seus processos ali de Deploy cultura devops etc você vai ver que não dá se você sofre para fazer o Deploy uma vez por semana do seu software Imagina você fazendo 20 30 por dia tá uma outra coisa aqui é observabilidade né uma das coisas mais complexas

que você tem em trabalhar com microsserviço é a parte de observabilidade por você tem que ver como que tá sendo a comunicação o sistema tá lento pro usuário Mas qual microsserviço tá lento qual microsserviço que tá deixando outro lento que tá deixando outro lento que tá deixando outro lento entende então esses tipos de coisas são extremamente complexas como que eu consigo saber que isso tá acontecendo Quais são os logs Como que eu consigo saber que essa chamada chamou um que chamou o outro né Quais são as métricas que eu tenho de todos esses microsserviços então

observabilidade é algo inegociável para quem trabalha com microsserviços na na realidade Inclusive para quem trabalha com sistemas monolíticos mas quando você trabalha com observabilidade em microsserviços essa parada vai o nível de complexidade à décima potência porque são vários caras se comunicando e você tendo que traquear a informação de um lado pro outro e um outro ponto é a parte de sre tá sre significa site reliability Engineering eu não tô dizendo que você tem que ter um profissional específico de sre na sua empresa Tá mas basicamente o que o sre faz ele tem a é uma

engenharia de confiabilidade e confiabilidade não é para garantir só que o Deploy funcionou que o rollback funciona a confiabilidade é garantir que a aplicação em si está funcionando da forma como ela funciona se não tá realizando o pagamento porque o Gateway tá com problema esse é um problema de confiabilidade mesmo que a sua aplicação não tenha problema não tenha não tenha culpa no cartório mas pro usuário final ela tem entende então quando a gente fala de sre tá e eu tô fazend falando de uma forma bem grosseira a gente tá pensando em confiabilidade como que

eu consigo ter métricas de conf para eu garantir que incidentes vão ser minimizados e se eles acontecerem Como que eu posso fazer com que eles não aconteçam mais legal agora quando que a gente pode utilizar microsserviços já de cara sem sair criando monolitos bom se você tem clareza do que tem que ser desenvolvido processos já estão Claros a o domínio já é conhecido pela sua equipe né os modelos de negócio eles estão validados na empresa a empresa tá vendendo um produto aquele produto já já vende já a empresa não vai mudar de atender pessoa física

e pessoa jurídica de um dia para noite né você já tem vários sistemas a empresa é grande Cara você não vai criar um software monolito juntando tudo para depois desgrudar novamente você já pode começar criando um uma estrutura ali de microserviço Tá talvez você não precisa criar ter uma granularidade muito grande Tá você não precisa ser tão granular Mas você já pode criar sistemas Porque se o problema é conhecido se na empresa tá validado tá isso aí é importante agora o que que normalmente a gente tem que ter que vai ajudar você nesse processo um

princípio da familiaridade a gente vai falar inclusive isso ah em algumas leis são quatro leis que eu vou passar embaixo logo logo aí para você o que que é o princípio da familiaridade galera é que o software para qualquer equipe para qualquer desenvolvedor mesmo que ele não tenha desenvolvido ele deve ser familiar toda vez que ele vai usar um software ele vai ver um ecossistema e etc mesmo que ele seja de Outra área quando ele olha aquilo ele já se sente mais em casa isso vai ajudar demais então Sabe aquela parada de você tem um

desenvolvedor que tem um ego do tamanho de um elefante um outro desenvolvedor que tem o ego tamanho de uma girafa e esses dois caras eu vou fazer do meu jeito porque o meu é melhor esses dois caras cada um pega um microsserviço completamente diferente aí quando você sai de uma equipe para outra parece que você tem que reaprender a empresa inteira simplesmente porque tem dois caras que não conseguem se conversar para ter um mínimo né de consenso para que o software fique mais parecido dentro de um ecossistema para diminuir a fricção tá de novos desenvolvedores

legal outra coisa que ajuda muito to kits internos né como que eu mantenho familiaridade padronização to kits ajudam PR caramba entendeu Você roda um projeto iniciar um novo projeto cria um escafo de lá alguma coisa assim já tem passas definidas já tem projetos definidos já tem emos definidos já tem um monte de coisa ali definida que por mais que você mude de forma geral arquitetura do software né não vai ser algo muito estranho quando outra pessoa pegar outra coisa infraestrutura adequada né se você tá trabalhando com um monte de microsserviço você tem que saber onde

que eu vou fazer o Deploy eu vou trabalhar com kubernetes v trabalhar com ecs eu vou trabalhar com Google Cloud Run com azure app service ou coisas desse tipo né como é que isso vai funcionar eu tenho essa infraestrutura adequada eu consigo gerenciar isso eu tenho pessoas que entendem sei lá de kubernetes ou a minha equipe ela entende o suficiente de kubernet para fazer o Deploy e utilizar um serviço gerenciado né ah e para isso eu tenho realmente é uma cultura Clara de devops né eu tenho realmente ah pontos específicos para garantir confi idade na

minha empresa eu consigo realmente manter essas coisas observáveis cara você tem isso que eu tô falando vai direto pra microsserviço porque provavelmente a sua empresa ela já tá num nível de maturidade maior tá muito diferente numa Startup que tá testando validando o produto já quer sair criando um monte de microsserviço cara tá perdendo tempo vai direto pro monolito legal mas a dica aqui é não leve a ferro e fogo o artigo do Martin f que tem quase 10 anos legal um outro ponto que é importante eu falar aqui são aquelas leis que eu falei que

eu ia que eu ia combinar de falar aqui para vocês inclusive galera muito mas muito disso que eu tô falando aqui para vocês está no nosso MBA em arquitetura full pych tá Ah em breve abrimos matrículas e você pode estudar com a gente por 18 meses um diploma reconhecido pelo MEC pela udade fsico de tecnologia a fctc legal mas o seguinte galera tem um algumas leis chamado leis de leman E belate se eu não me engano tá e existem quatro pontos principais nessas leis uma lei é a lei da mudança contínua falando que o software

tá ao longo do tempo ele vai continuar mudando e se você não conseguir adaptá-lo a essa mudança ele vai falhar miseravelmente e não vai conseguir de acompanhar o negócio Óbvio parece né lei do crescimento da complexidade que ele acaba dizendo é que conforme o software cresce maior a familiaridade dele vai crescer ao menos que você trabalhe de forma explícita para diminuir a complexidade desse software ao longo do tempo e é aí que é a grande pegadinha se você já trabalha faz um bom tempo você já vi algum software nascer entregando um monte de feature ao

mesmo tempo e conforme o tempo passa cada vez vai ficando mais difícil entregar cada vez vai ficando mais difícil de manter e daí um monte de gente quer reescrever o software Por que que isso acontece porque a complexidade do software ao longo o tempo Aumentou e ela sempre vai aumentar o que você pode fazer com essa complexidade é Minimizar e o que que é Minimizar Essa complexidade é trabalhar de forma intencional de diminuindo a complexidade Como que eu faço isso enquanto tem um monte de gente programando para entregar feature você vai pegar uma pedaço da

sua equipe e trabalhar para refaturar melhorar manter testes facilitar várias coisas remover partes que não estão mais funcionando o remover partes do software que não fazem mais sentido tudo isso para tirar a complexidade tá então desenvolver um software Ah não é só criar features é manter mas manter um software não é só continuar melhorando é reduz uzir explicitamente a complexidade e com certeza se você olhar seu softare em 10 minutos você vê que existem partes extremamente complexas e que se alguém tivesse gastado um tempo ela não ela não estaria dessa forma como tá hoje uma

outra uma outra lei é a lei da Conservação da familiaridade que eu falei lá em cima quanto mais familiar o software parece melhor é para todo mundo que vai trabalhar né e a lei da conservação do esforço tá ah galera um ponto é importante aqui que eu quero que vocês entendam pessoal tudo isso parece são coisas óbvias tá por exemplo lei da conservação do esforço basicamente o que ele tá dizendo é que por mais que você tenha ao longo do tempo um software sendo desenvolvido quanto mais tempo se passa maior vai ser o esforço que

você vai ter para entregar novas features tá então preste bem atenção nisso isso acontece agora qual que é a grande sacada E por que que isso é importante pra gente Pessoal isso é importante porque você já sabe a pegadinha antes dela te pegar na safadeza você já sabe que isso vai acontecer e se você já sabe que isso vai acontecer você já pode brigar com isso desde o início tá a gente agora a gente tem a experiência de 50 anos na área de tecnologia mais que isso entendeu então o que que acontece a gente já

viu muita coisa da errado mas às vezes por falta de estudo a gente comete erros que cara galera lá de 1970 já tava cometendo entende então vamos pensar sobre isso e agora galera antes de irmos a alguns cases que eu quero trazer aqui para você eu quero falar sobre acoplamento aqui para você toda vez que a gente fala em acoplamento todo mundo torça o nariz porque parte do princípio que acoplamento É algo ruim e eu não discordo mas Eu discordo parcialmente que que eu tô querendo dizer o software ele precisa de acoplamento porque se ele

não tiver acoplamento os pedaços deles não estão juntos e ele não vai funcionar eu tenho meu ombro eu tenho meu braço Eu tenho minha mão se esses Meus Pedaços fossem totalmente separados e não estivessem acoplados Não adiantaria eu ter nada o problema é que quando a gente tem um acoplamento excessivo ISO faz com que a gente Reescreva muito código a gente quebre muito código e a gente faa com que o nosso código fique muito mais complexo para ter algumas mudanças que às vezes vão refletir diretamente no negócio tá Isso é fato você tem que brigar

com o acoplamento ao mesmo tempo mas você tem que abraçar o acoplamento porque você sabe que ele é necessário Como que você consegue fazer isso existem formas de você medir o acoplamento da sua aplicação tá e inclusive entender para quem você vai dar a cada tarefa inclusive tá se você olhar a gente tem dois tipos de acoplamento eferente e aferente Tá o que que é um acoplamento eferente o acoplamento eferente é um acoplamento onde o seu componente depende do outro por exemplo aqui eu tenho o z dependendo de y eu tenho o x dependendo de

y o w dependendo de y esses caras aqui são acoplamentos referentes Tá qual que é o problema de um acoplamento eferente ele torna o seu código menos estável por quê Porque ele Depende de código de terceiro ou de outro componente e se o outro componente quebra o que que acontece adivinha só o componente referente também vai quebrar junto então quanto mais dependência o seu componente tiver mais mais menos estável ele vai ser o z o X e o y aqui eles o z o x e o W eles são instáveis mais instáveis porque eles dependem

do Y se o y quebrar quebra o z o X e o W agora o acoplamento aferente ele funciona diferente por quê Porque ele Depende de menos pessoas e se ele Depende de menos pessoas ele é mais estável porque ele se autog garante né quando eu crio o meu sistema eu crio os meus testes tá tudo do jeito que eu fiz e eu não dependo de ninguém a estabilidade é maior agora se eu dependo de um cara e se esse cara quebra esse cara vai me quebrar junto entendeu agora por que que iso é importante

você entender tá olha os números ali ó o ca é aferente e o ce é o eferente Se você olhar o z o X o w você vai ver que cada um tem é igual a um porque ele Depende de um componente ali eferente no caso do Y ele tem três componentes que dependem dele ou seja três aferentes e ele tem zero eferentes Então nesse caso o y ele é mais a aferente ele é mais estável aqui pra gente agora por que que eu tô falando isso galera até a forma de como você passa a

tarefa pros outros desenvolvedores muda completamente o rumo do seu software Por que que acontece vamos imaginar que eu tenho quatro componentes no meu software e daí eu chego entra sei lá um um desenvolvedor Júnior e eu vou passar algum trabalho para ele eu falo cara refat para mim um componente que vai me ajudar aí você tem quatro componentes para você passar para ele refaturar você tem quatro componentes e um desses componentes você vai escolher para ele refaturar Qual componente Às vezes você vai passar você vai passar o y tá você vai passar justo o cara

que é mais estável e que tem mais gente dependendo dele se esse desenvolvedor mais júnior galera nada contra Júnior mas tô dizendo pessoas TM menos experiência se alguém quebrar esse Y vai quebrar o z o X e o W entende o que eu tô dizendo Então quando você consegue olhar o acoplamento dentro da sua própria aplicação você começa a ver Quais componentes são mais críticos e quanto mais crítico é o acoplamento mais Sênior a pessoa tem que ser para mexer com ele Ok então você não vai dar um componente estável que tem menos dependências tá

para alguém que tá começando agora tá isso aí é muito importante porque ele vai quebrar todos os caras que dependem dele tá então era essa pegada que eu queria passar rapidamente de acoplamento Se você olhar aqui isso é um um dos slides que a gente usa no nosso MBA em arquitetura full cycle agora galera cases mais práticos e coisas importantes que que eu queria trazer aqui para vocês para vocês entenderem ecossistema como as coisas se comunicam e como um sistema monolítico aos pontos ele pode ser quebrado em algumas partes e como você pode construir um

ecossistema em volta dele por que que eu tô dizendo isso porque isso aconteceu com a gente aqui na full pych tá então o lance é o seguinte galera ah a gente tem um sistema monolítico tá que o primeiro comite dele foi 2012 eu que fiz tá Ah ele é feito em PHP a gente começou a ter testes automatizados dele lá em 2012 tá Ah do dia zero sempre a gente trabalhou com teste o foco principal desse sistema na época era o quê cobrar para alguém poder contratar meu serviço e a pessoa Navegar e assistir vídeos

tá olha aqui o Middle Alt galera o que gerava negócio aqui para mim é cobrar e assistir vídeo um mon de crud Zão aqui para mim eu fiz da forma mais simples possível mas aqui eu tomei cuidado legal então regras partes mais críticas aqui foi o meu Middle out vamos dizer assim OK 2024 como é que tá hoje a nossa estrutura interna aqui da full cycle tá ah muita gente pode falar que a gente complicou demais ou etc mas galera na real isso isso aí eu acho que ficou de uma forma bem organizada que a

gente não sofre no dia a dia para manter esses caras tanto porque muitos desses caras eles são Ah bem estáveis o nosso modelo de negócio ele é estável a não ser quando por exemplo você compra uma faculdade e você aí começa a ter que implementar um monte de outras coisas tá mas de forma geral o que que acontece galera o nosso sistema Core aqui ele começou em 2012 ele ainda roda hoje em dia tá a e o que que ele faz hoje em dia basicamente ele tem todos os usuários ali dentro ele tem todos os

cadastros dos cursos né eles tem toda a parte de checkout ali pra gente trabalhar ah ele tem ali os dados de cadastro ele assim ele tem muita informação inclusive dados financeiros também né a parte de cobrança a faturas Como é que vão ser as notas fiscais eu não tô dizendo que ele emite nota fiscal mas que ele tem todas as informações informações operacionais da empresa está no banco de dados dele por quê Porque ele é o nosso centro da verdade nesse momento OK agora ah por onde que eu vou começar a falar aqui para vocês

inicialmente como a gente precisava trabalhar muitos com vídeos a gente teve diversas versões pra gente utilizar vídeos tá uma versão era um software que a gente desenvolveu utilizando Gol né onde você jogava os MP4 dentro de uma pasta esse software ficava olhando fazia o transcoding todo subia lá para um Bucket da WS esse transcoding ele já utilizava DRM e já botava tudo para funcionar legal mas assim criar toda uma interface daquilo desse sistema era complexo e a Amazon aws um tempo ela lançou um serviço chamado elal tá e esse elemental é um serviço exatamente para

trabalhar com vídeos então o que que a gente fez no final das contas a gente criou a gente tem o nosso MP4 né que é o vídeo que a gente tem bota num Bucket o Bucket ah chama uma lambda function que vai chamar na o elemental que vai fazer o transcoding da nossa aplicação vai fazer comunicação com o nosso provider de DRM vai receber a chave do provider de DRM vai fazer o transcoding vai num Bucket da S3 tá e toda vez que o nosso lms né onde o usuário o aluno faz o acesso quando

o usuário pede o vídeo bate numa CDN a gente tava usando a akamai a akamai bate no Bucket D3 baixa nas próximas vezes isso aqui é replicado por vários lugares do Brasil para diminuir a latência então é basicamente isso a que a nossa parte de vídeos fazia tá agora o que que que acontece tem muita coisa aqui e eu quero trazer para vocês um pouco mais de perspectiva de negócio tá que que acontece hoje em dia a gente atende empresa tá e o que que acontece quando a gente atende empresa existem planos empresariais as empresas

controlam as licenças a gente consegue remover adicionar usuários etc então o que que acontece galera meu o nosso negócio é muito claro já tá funcionando a gente criou um sistema aqui onde a gente faz essa ponte para ficar fácil para essa utilização simples e fácil aqui pra gente trabalhar porém esse nosso sistema Core Ele tem muita informação e ele gera muitos eventos tá E esses eventos gerados eles são ouvidos por diversos sistemas que a gente precisa ter então eu vou dar um exemplo para você quando eu tô aqui no meu lms o que que acontece

eu executo diversos eventos clico no vídeo vou para lá vou para cá isso aqui é erado bate o nosso sistema Core nosso sistema Core joga isso aqui para uma fila tá essa fila aqui por exemplo tem os dados do Progresso do aluno que cai num sistema específico nosso onde a gente consegue ver tudo que o aluno faz tá cada detalhe que ele navegou a gente consegue saber Opa teve uma compra para gerar nota fiscal gerou um evento caiu numa fila vai para um sistema externo que é o nosso RP que a gente não desenvolve e

esse cara cuida de toda a nossa parte fiscal e tudo mais legal outra coisa tive fez uma nova contratação alguém virou um aluno pum vai no nosso hubspot que é o nosso CRM legal na hora que esse cara virou o aluno nesse nesse momento aqui pra gente a gente pode fazer um monte de coisa aqui pra gente tá a gente consegue ter todas as informações a gente sabe se esse aluno ele pode ser potencial para contratar um outro curso na hora de gente fazer os atendimentos os chamados as dúvidas esse tipos de coisa tá tudo

registrado no nosso CRM o aluno navegou no nosso site o aluno navegou pela nossa plataforma tudo ali fica registrado porque quando a gente quer entender como que tá o ciclo de vida do nosso aluno a gente ol no nosso CRM Ok por exemplo a gente tem o nosso site quando alguém preenche um formulário no nosso site isso cai no nosso CRM né aí olha só que interessante Às vezes você preencheu um formulário não sei como que você caiu aqui nessa nesse evento ou se você é já aluno alguma algum momento você já preencheu um formulário

nosso quando você preenche um formulário nosso tá a gente tem algumas informações suas essas informações a gente manda para um sistema que a gente tá aqui criando a um sistema de Lead scoring Esse sistema de Lead scoring basicamente ele roda uma fórmula para cada produto que a gente tem baseado nas suas características e a gente retorna isso aqui pra gente pro CRM falando olha o Wesley ele é um cara que ele é ideal para fazer o MBA já o Joãozinho o MBA não é para ele mas o curso full pych é fit Total esse Juliano

ele cara ele tem o perfil para ele fazer o nosso curso de Tech Lead entende por que que isso é importante PR gente porque a gente quer saber o que como que a gente pode te ajudar e para isso a gente tem que entender seu perfil Então a gente tem um sistema que só fica analisando o perfil das pessoas que estão no nosso CRM pra gente ser muito mais assertivo na hora de poder ajudar esses alunos tá uma outra coisa que acontece aqui também é toda vez que você cai numa página nossa ó participe de

um evento né ou até mesmo para participar do própria semana do arquiteto ou alguma coisa esse tipo você tá numa plataforma Nossa focada em eventos essa plataforma ajuda a gente fazer as nossas imersões ajuda a gente fazer a captação de pessoas que vão participar com a gente pra gente mandar material para organizar grupos de WhatsApp a gente tem um monte de coisa nessa nossa plataforma né Então essa plataforma ela consegue nos ajudar até criar as Landing pages para que você possa fazer a compra de um curso né e o que que acontece toda vez né

que cai informações ali e são informações importantes an a gente enfila isso e vai pro nosso RM Por que que a gente trabalha muito com filas aqui galera para garantir resiliência imagina que alguém preencheu um formulário aí eu vou mandar pro CRM o CRM tá fora do ar eu perdi esse preenchimento não cai numa fila e daí esse cara ali a gente consegue fazer o retry ali e etc legal coisas interessantes Compramos uma faculdade a fctc galera nosso objetivo né C Tec é ser uma faculdade extremamente tecnológica né hoje em dia quando você termina um

curso de pós--graduação numa faculdade às vezes demora se meses para conseguir o certificado Hoje em dia a gente tá trabalhando duro para que depois que você envia os nossos docum os documentos você já emita o certificado automaticamente sem depender de um monte de coisa então a gente está trabalhando para isso então a gente tem sistemas específicos para integrações de certificados homologados pelo mesma coisa sistemas internos para fctc que geram eventos então o aluno fez uma compra caiu no nosso financeiro a gente tem que saber que esse cara é um aluno esse aluno em algum momento

vai preencher ou vai subir as documentações dele num painel Quando ele subir nesse painel a gente tem que validar se essas documentações não são falsas então tem bastante coisa legal vídeos o cara clicou participou assistiu um vídeo a gente tem todas essas informações também agora conforme o tempo foi passando por exemplo essa parte aqui começou a ser muito cara burocrática mas ela foi essencial pra gente numa época que não tinha tantas opções de CDN transcoding e coisas desse tipo hoje em dia a gente já tem sistemas que facilitam muito a vida então por exemplo o

nosso sistema hoje em dia quando a gente vai subir um vídeo no nosso sistema Core a gente sobe um vídeo no sistema Core esse sistema ele bate num sistema de terceiro que a gente contratou tá esse sistema de terceiro joga para um outro sistema que vai fazer o transcoding e ele mesmo já é a própria DRM e a e a CDN também E aí uma vez que esse cara tá feito a gente consegue fazer com que os nossos alunos assistam os nossos vídeos legal outra coisa novamente galera a gente tem o nosso sistema mas quando

o aluno precisa tirar dúvidas ele vai no nosso fórum Então a gente tem um sistema de fórum né mas o fórum hoje em dia a gente utiliza ia a gente tem a ia da full pyc como é que funciona o fórum bate quando alguém faz uma pergunta no fórum né o que que acontece a gente bate no sistema da iada full cycle a iada full cycle bate na api da openi mas a gente tem um fine tunning da da api da da na api da Open ai E além disso a gente tem alguns embeddings eu

não coloquei todos os detalhes aqui e a gente acaba tendo o nosso próprio modelo customizado e daí a gente responde de volta aqui pro usuário porém no nosso lms né que é o learning Management system que é onde o aluno estuda com a gente o que que acontece aqui também na hora que ele tá assistindo o vídeo ele pode ter o chat e tirar dúvidas inclusive do vídeo que ele tá vendo o nosso chat sabe o vídeo que ele tá vendo e consegue tirar dúvidas especificamente daquele vídeo ou do curso como um todo como que

isso acontece o lms bate no iada full cycle e cai nesse processo aqui legal então quando você começa a ver esses tipos de coisa galera você começa a ver aqui diversos sistemas se comunicando e tudo isso galera foi baseado num sistema que nasceu em 2012 pedaços desses sistemas tá Eles foram quebrados em microsserviços por exemplo o fórum nosso era aqui a gente Um dia resolveu criar um fórum totalmente novo porque ia ficar ia ser muita regra de negócio para um Core e a gente conseguia separar as equipes galera microsserviço também não é só para desacoplar

sistema microsserviço também é para organizar a equipe tá lembre-se disso também nesses tipos de ponto ok então para que você tenha uma ideia é basicamente assim hoje como que a gente opera e a gente tem tem diversos sistemas que são componentes e esses caras eles vão crescendo ao longo do tempo a gente tem um Core muito estável e isso permite que a gente brinque em volta de tudo isso a gente trabalha muito com fila quando a gente faz chamada direta a gente tem diversos mecanismos de retry a gente tem outbox pattern exatamente para garantir mais

resiliência para garantir que a gente não perca informação ou qualquer coisa desse tipo tá são somos perfeitos temos bugs etc Claro galera mas a gente faz múltiplos deploys todos os dias e todos os dias aqui dentro e o nosso ecossistema ele vai crescendo coisas a gente vai desativar aos poucos como essa parte aqui de cima outras partes a gente vai melhorar outras partes a gente tá terminando de implementar mas a ideia que eu quero que vocês entendam é que você sim pode partir de um sistema monolítico aos poucos quebrar esse sistema imagina Antes aqui nesse

Core eu conseguia ver também o que o aluno tava assistindo mas era muito complexo eu queria ter um painel um dashboard onde a gente vê a gente vê o aluno que mais tá assistindo que menos tá assistindo evasão todos esses tipos de coisa Poxa cara isso aqui virou um sistema próprio não cabia mais aqui dentro ia ficar muito complexo entende então às vezes facilita muito a vida a gente ter um ecossistema desse aí Bacana Então isso é para você entender aqui como que um sistema de 2012 agora em 2024 a ainda funciona e um ecossistema

que a gente foi criando ao longo dele sem precisar reescrever sistema do zero galera a coisa que eu mais brigo no dia a dia é quando alguém quer ficar reescrevendo o sistema Esquece isso galera Esquece isso reescrever sistema não é um privilégio de todos e normalmente empresas que deixam reescrever sistemas ou tão mal assessoradas ou ela tá Mudando completamente o modelo de negócio porque fora disso raramente você vai reescrever um sistema dos zero tá agora eu quero compartilhar uma outra coisa aqui com vocês pra gente acabar essa história tá ela ela tem muito mais a

ver com problemas no mundo corporativo e traquejo e soft Skills que você precisa ter para você lidar com situações estressantes na sua vida galera eu sei que ti é uma profissão extremamente estressante é para caramba galera eu já tive diversos burnouts e inclusive esse Case aqui que eu tô vou contar para vocês agora foi um deles Tá mas o lance é o seguinte galera um dia um meu chefe chegou e falou Wesley bote seu terno sua gravata Ah vá nesse edifício a gente vai se encontrar lá com uma reunião com um cliente gigante e a

gente vai vender e a gente vai pegar um projeto grande pra gente Poxa fiquei super animado cara eu não lembro que época que ano que foi eu acho que foi 2006 2005 algum aluma coisa desse tipo eu lembro que eu já usava Linux por um único motivo Tá eu já falo para vocês o lance é o seguinte chegamos lá um dos maiores escritório de advocacia do Brasil uma parada totalmente formal eu sento lá na mesa de reunião com o meu Linux aberto de repente chega um batalhão de gente lá né o gerente de tecnologia diretor

de tecnologia alguns desenvolvedores e chega o meu chefe ah de cara eu comecei a ver que os caras todos eram da eram Microsoft teros tá hoje em dia não existe mais Microsoft teros naquela época galera existia uma briga muito grande de Microsoft com open source tá a a a época ali do Bill Gates com Steve baummer teve assim foi um atrito gigante porque a Microsoft ela via realmente o open source Linux e etc ah como algo com inimigo quando trocou e tem agora o o novo CEO a a Microsoft mudou o primeiro dia que o

cara virou ele fez um coraçãozinho que a Microsoft ama o Linux tem a própria versão do Linux mas naquela época era uma briga de ego era algo ridículo tá e o que que acontecia que essa empresa só entrava produto da Microsoft não entraria nenhum produto open source na hora que eu percebi que ali era só Microsoft eu fechei o meu notebook porque eles iam ver que eu tava usando o Debian o Debian ou era o bunto que tinha acabado de lançar instalado o CD do mto que eles mandavam pelo correio inclusive tá e eu percebi

que eles tinham uma dificuldade ali que era desenvolver a intranet deles eles tinham diversos sistemas na empresa e eles queriam integrar esses sistemas todos na intranet e naquela época né a a gente tinha o Microsoft sharepoint eu já tinha ouvido falar no sharepoint sabia que ele era PR intranet mas eu não sabia nem qual que era o logo do sharepoint eu nunca tinha feito não visto não tinha visto nem a interface do sharepoint os caras tinham zero documentações da dos sistemas que eles queriam entregar integrar e eu tinha zero conhecimento da fer e eles tinham

muito problemas de resiliência ou seja eles tentava integrar o sharepoint e dados ficavam pela metade porque não tinha fila não tinha política de retry não podia nada E além disso eles queriam fazer uma customização na interface monstra e que o sharepoint ele era inteiramente engessado para fazer e no meio dessas reuniões aparecia Às vezes a diretora de marketing lá para falar que tava tudo muito ruim porque o design não tava Ok e tudo mais mas esse aí não é o caso por que que eu tô contando essa história aqui para vocês pessoal porque eu passei

por uma situação e que eu não desejo para ninguém e que eu prometi para mim que enquanto eu fosse empresário nenhum funcionário meu iria passar por isso que que é o seguinte o meu chefe chegou e me apresentou lá olha isso aqui é o Wesley fui apresentado para todo mundo e tudo mais aí o que que começou a acontecer apareceu um monte de cara que era desenvolvedor dentro daquela empresa gerentes todos os caras certificados na Microsoft também com certificação do sharepoint e os caras não conseguiam implementar aquela parada aí o meu chefe virou e falou

assim Galera vocês estão aqui com o cara o é o cara que vai resolver o problema de vocês com sharepoint ele é especialista nessa parada então ah vamos falar com ele que eu acho que ele vai conseguir trazer um algo aqui para conseguir resolver pessoal eu não sei qual seria a sua reação naquele momento tá o mundo daquela época galera é um pouco diferente do mundo de agora tá 10 anos 15 anos atrás por qu as coisas eram muito formal qualquer reunião você tinha que de gravata as pessoas levavam as coisas muito a sério o

programador naquela época não era aquela pessoa que às vezes ia de shorts pra empresa sabe então a parada era tão formal e daí de repente o meu chefe fala que eu sou especialista eu não tinha visto nem interface do negócio e daí eu falei assim cara como o que que eu vou fazer se eu falar que eu não se sei nada eu vou acabar com a empresa e com o meu chefe posso até ser mandado embora eu achava que eu não ia mas sabe aquelas decisões que você tem que tomar em questão de segundos tá

Eu não tomei essa decisão de expor o meu chefe dispor a empresa e falar que eu não sabia sharepoint e que todo mundo que estava naquela sala e que reservou aquela sala por uma hora ia perder tempo porque a gente não ia conseguir atender eles Essa era uma situação a outra situação era eu falar sim sou especialista em sharepoint eu sou fodão Ah e vamos resolver seu problema aqui eu não podia falar isso também porque eu não sabia como resolver o problema que esses caras tinham eles começaram a me mostrar ali o problema eu não

sabia nem do que se tratava eu não entendia mostrava as tabelas lá do sharepoint eu não entendia nada então eu sabia que esse caminho não era um outro caminho adequado para eu seguir Qual foi o caminho que eu consegui perceber naquele momento euce que aqueles caras eles eram extremamente técnicos Mas eles estavam com alguns problemas conceituais e esses problemas conceituais estavam atrapalhando como eles iam desenvolver o software eles até tinham condição de desenvolver o software mas o momento que eles estavam tentando desenvolver o software tinham muitas coisas que não estavam Claras no projeto para eles

e naquele momento essa me ajudou porque eu já tinha passado por muitos projetos e eu já tinha passado por situações que esses caras tinham passado obviamente em tecnologias diferentes então eu pensei Como eu posso não passar vergonha e falar que eu não sei o sharepoint E como que eu consigo gerar uma boa impressão para eu fechar o contrato naquele momento tá E hoje você pode pensar o qu ético foi o que eu fiz ou que eu não fiz tá o fato é que eu não falei explicitamente que eu era especialista em sharepoint porque eu não

ia mentir tá eu não gostei inclusive da inferência que o meu chefe fez como se eu fosse especialista Tá mas o que eu fiz no final das contas é quando começaram a mostrar um monte de coisa do sharepoint eu falar galera eu não tô entendendo nada do que vocês estão falando para mim foi a primeira coisa que eu falei para eles eu não entendo nada que vocês estão falando para mim vocês estão falando sharepoint de partes que eu nunca vi vocês estão falando de sistemas que vocês já tem vocês estão falando complexidade de detalhes de

como aparecer alguma coisa no sharepoint Tá mas vocês não TM isso isso isso isso claro ah peguei o Notebook do meu chefe que tinha Excel porque o meu tinha o openoffice Na época eu acho porque era Linux e eles não podiam ver que eu usava Linux e eu falei galera eu preciso entender melhor o projeto de vocês criei uma planilha lá no Excel né e não foi enrolação não tá galera eu não fiquei enrolando eu realmente criei uma planilha no Excel organizei ali o papel as áreas o que eles estavam tentando implementar o papel de

cada um permissões e coisas ali e no final daquela reunião todo mundo explodiu a cabeça e falou assim caraca é por isso que a gente não tava conseguindo fazer a gente nem sabia o que a gente não sabia esse cara chegou aqui e mostrou que o problema nosso não tá no sharepoint o problema nosso aqui tá em não saber o que a gente não sabe galera nesse momento foi o momento que a gente fechou o contrato a gente saiu ali com o projeto só faltava mandar proposta e assinar a gente mandou a proposta e a

gente fechou o projeto obviamente eu não sabia o sharepoint tivemos que pedir ajuda tivemos que comprar livros tive ajuda até de pessoas de Portugal naquela época depois a também que eu trabalhava um tempo depois também virou Mega especialista em sharepoint tinha todas as certificações e tudo mais mas o fato que eu tô querendo dizer aqui para vocês pessoal é que eles tinham diversos sistemas sistema de gerenciamento de documentos o site que recebia currículo e daí queria cair o currículo no sharepoint fazer um outro processo Ah tinha tinha muitos detalhes ali galera mas o que eu

percebi Ali era a imaturidade dos desenvolvedores em não entender do negócio e quando eu captei esse ponto fraco deles eu conseguir desviar o foco do sharepoint e que realmente deveria ter sido desviado mesmo provavelmente mesmo que se eu fosse um mestre do sharepoint naquela época eu não iria falar de sharepoint porque tinha um problemas abaixo disso por que que eu tô contando essa história aqui para vocês pessoal foi para contar que quando o meu chefe falou que eu era especialista em sharepoint eu quase desmaiei e que a minha mão começou a tremer que eu comecei

ter palpitação né que eu tive que me fazer me virar nos 30 né foi uma reunião de uma hora que a minha adrenalina tava lá em cima eu tô falando isso para você porque eventualmente Você pode passar por isso eu juro por Deus que eu não quero jamais que você passe por qualquer situação parecida com essa tá mas o fato é Em alguns momentos você vai ser desafiado em alguns momentos você não vai entender do que as pessoas estão falando mas você tem que entender que às vezes o que as pessoas estão falando não importa

naquela fase do projeto e foi isso que eu consegui perceber que o que eles estavam fazendo ali naquela fase do projeto era inútil porque tinha muitas outras coisas para serem definidas e organizadas e tudo mais tá galera eu sei que essa aula ficou meio comprida eu sei que eu falo para caramba mas de coração tá eu espero que vocês consigam ter entendido o que eu quis trazer aqui para vocês eu quis trazer um pouco de arquitetura de software falar de acoplamento falar um pouco sobre como que a gente organizou as coisas na full cycle a

partir de um sistema monolítico que desde 2012 né então a gente tem bastante coisa aqui para explorar soft Skills esse gingado sabe galera Às vezes as pessoas falam de soft Skills e fala ah é habilidade de comunicação e tal Ah isso aí eu vou desenvolver galera não é assim tá essas habilidades fazem com que você consiga sair de uma situação que você pode sair humilhado para uma situação onde você fecha projeto de milhões você entendeu então isso aí é extremamente importante comece a perceber se você tem ou não tem traquejo para conseguir lidar com situações

e com pressão tá ok então a gente falou sobre tudo isso a gente falou sobre Middle out a gente falou sobre o artigo do Martin faller 2015 pense bem eles falou isso em 2015 Será que ele acha isso até hoje talvez sim talvez não tá a gente falou de algumas leis Então galera eu realmente do coração espero que você tenha aprendido algo nessa aula tá no próximo vídeo a gente vai ter bastante coisa para falar a gente vai falar também sobre a gente vai falar sobre sre a gente vai falar sobre entrega de software a

gente vai falar sobre confiabilidade a gente vai fazer como que você consegue fazer Deploy todos os dias da sua aplicação garantindo confiança tá que as coisas não vão dar errado e se elas darem errado Como que você volta trás tá então galera espero que vocês estejam curtindo realmente esses vídeos tá E até o nosso próximo vídeo eu quero que você tenha aproveitado um grande abraço aí para vocês e até a próxima r [Música]