fala ARQ tudo 100% com você? No conteúdo de hoje vamos falar sobre arquitetura de software você vai entender como é que a arquitetura funciona e quais são os grandes Pilares as grandes caixinhas para se fazer um bom trabalho de arquitetura de software Bacana Então bora lá ar caso você ainda não me conheça muito prazer eu me chamo Carlos Pisani e por aqui eu ajudo profissionais como você a se tornarem Fera em arquitetura de soluções de software de sistemas arquitetura de ti como um todo e fica o convite de você se inscrever por aqui independente da
mídia que você estiver me acompanhando para receber mais conteúdos como este Então bora falar um pouquinho sobre arquitetura de software algo que muitas pessoas têm dúvidas sobre Poxa Qual que é o papel do arquiteto que que o arquiteto faz qual que é a diferença entre um arquiteto de software soluções sistemas então nessa série de conteúdos nós vamos falar tudo isso e hoje começando falando sobre arquitetura de de software o arquiteto de software é uma figura muito importante em projetos técnicos em especial quando estamos falando da construção da concepção de um produto por ele é a
figura que vai ajudar na tomada de decisões estruturais a desenhar o mapa né de toda a aplicação aonde as caixinhas ficam só que para isso precisa seguir uma certa receitinha de bolo e a receitinha de bolo não é necessariamente as decisões já tomadas Mas é uma sequência de coisas que é preciso fazer para você fazer um grande trabalho de arquitetura Tudo bem então vamos começar do início aqui pelas premissas essa aqui a primeira coisa que o arquiteto precisa fazer levantar identificar as premissas aqui na ArcH na nossa metodologia nós temos uma metodologia eh que nós
ensinamos inclusive PR os nossos alunos e nós aplicamos ela aqui na ArcH a minha consultoria de arquitetura e nessa metodologia a gente tem as premissas que são ponderáveis que a gente chama de requisitos arquiteturais e os não ponderáveis o que não dá para colocar um peso para eles que são as variáveis arquiteturais isso tudo são premissas eu preciso juntar todas essas premissas em outras eh metodologias de trabalho a gente tem ali eh requisitos funcionais não funcionais e ambos na maioria dos casos impactam nas decisões a nossa metodologia não é diferente a gente tem premissas funcionais
e não funcionais a gente só categoriza de uma outra maneira para ficar mais fácil de se trabalhar com as premissas e esse step ele é muito importante porque com ele nós conseguimos fazer todo o restante do trabalho de arquitetura sem as premissas o arquiteto acaba dependendo muito da experiência dele isso acaba virando mais um trabalho de opiniões né baseado logicamente nas experiências profissionais do arquiteto do que em Fatos ou seja de uma maneira científica então é importante que o arquiteto tenha antes de mais nada combustível né informações para ele poder começar o trabalho dele de
arquitetura senão realmente vai acabar ficando uma coisa muito subjetiva e o nosso objetivo aqui é ter soluções que sejam amplamente direcionadas fundamentadas e objetivas tá bom bem então uma vez que eu tenho essas premissas identificadas e levantadas o que que eu vou fazer na sequência entender o que que é a qualidade magicamente depois de de termos aqui as premissas em mãos nós vamos entender claramente O que é a qualidade pro nosso projeto porque a qualidade ela é subjetiva ela varia Ok pode ser que tenha um código perfeito lá por trás super bem feito com as
melhores práticas de programação usando DDD usando tudo que você pode imaginar ali de boas práticas de programação e na hora que a gente entrega o produto a percepção pro usuário final né que vai acessar ali o aplicativo dele eh é que a aplicação é lenta é ruim é muito pesada esquenta o celular ou então do nosso stakeholder que custa muito caro né a infraestrutura é muito pesada é muito cara então se a gente não entende de essas premissas iniciais né que vem do do step um a gente também não consegue definir o que que é
qualidade pro nosso produto e entenda a arquitetura tem diretamente ligação com qualidade Por exemplo quando você vai comprar uma casa você olha pra planta da casa e aquela planta se ela não te agradar você não compra aquela casa né tem que ter ali a quantidade de quartos a estrutura ali Poxa a quantidade de Suites a o a ligação né entre um cômodo e outro tem que fazer sentido para para você e tem que ser algo que te agrade a proximidade né a localização do imóvel quantidade de vagas de garagem e tudo mais então na arquitetura
de software não é diferente a gente precisa ter uma visão Ampla e abrangente do que é que as pessoas os steakholders querem efetivamente e do que que o nosso usuário final a gente tem um link tá entre essas duas coisas eu tenho aqui os stakeholders que estão colocando dinheiro no projeto para aquele projeto acontecer que tem ali objetivos estratégicos e do outro lado eu tenho o usuário final as pessoas que vão consumir o produto que nós vamos gerar Neste contexto o arquiteto precisa entender as duas coisas para conseguir montar uma solução desenhar uma solução projetar
uma solução que seja compliance tanto com as necessidades desejos do nosso stakeholder né dos nossos stakeholders quanto dos usuários que vão eh utilizar a nossa aplicação Então esse link todo é responsabilidade do arquiteto e veja como é importante se a gente a gente não tem essa figura fazendo esse meio de campo entendendo todas essas visões e transformando Isso numa solução o que vai acabar acontecendo é que eu vou ter uma solução que vai ter uma longevidade muito curta ou seja vai durar pouco tempo vai ficar pouco tempo em produção eu vou precisar substituir rapidamente por
quê ou ela não agrada os nossos usuários finais e vai ter reclamações etc etc a gente vai ter que descontinuar jogar fora e fazer de novo ou vai nascer totalmente fora da linha estratégica do pensamento estratégico o qual ela foi concebida e esse afastamento tanto da linha estratégica referente a custos ou a qualidade mesmo no tocante a segurança no tocante a volumetria suportada né tanto nesse lado eh do dos nossos stakeholders quanto do lado dos nossos usuários finais se não tivermos um alinhamento a gente vai acabar tendo problema de qualidade muito forte e isso vai
condenar a nossa solução a uma longevidade muito curta bom bom e uma vez que a gente já tem as nossas premissas levantadas e uma visão Clara do que é a qualidade pro nosso produto entra aqui o nosso terceiro step que é a definição de padrões e também a definições de guias aqui tá esse é o nosso terceiro step Por que que isso entra aqui agora né logo depois de qualidade porque os padrões que eu vou adotar são as primeiras decisões que eu tenho tá são as primeiras decisões relacionadas a como nós iremos criar o nosso
produto e aqui é importante nós termos em mente que as áreas estratégicas de negócio elas trazem pra gente o porquê o que que é o nosso negócio O que que o para quem que é aquele produto né que nós estamos construindo e o arquiteto assim como todos os outros técnicos eles trazem o como então nós temos o que o para quem o por certo vindo das áreas de negócio as áreas funcionais e o time de arquitetura entra com como ele entende como resolver aqueles problemas beleza e uma das maneiras de se resolver esses problemas são
com padrões padrões de arquitetura padrões eh de projeto muitas vezes aplicados né dentro de uma solução específica Então os padrões são a base para começar a resolver os problemas que nós temos no nosso projeto então entender profundamente os padrões que nós iremos aplicar também é importante e essa é uma capacidade que o arquiteto precisa ter conhecer muito bem vários padrões né E os que ele não conhece conhecer saber como buscar como procurar como conhecer padrões e se você quer saber como estudar como aprender padrões nós temos um conteúdo já disponível aqui no nosso canal que
explica exatamente sobre esse tema então basta você clicar no card que eu vou deixar aqui ou então na descrição do vídeo também vou deixar o link aqui do nosso conteúdo para você assistir depois que acabar esse aqui beleza além dos padrões o arquiteto também precisa definir Os guias que o time de desenvolvimento vai utilizar tá então você vai ter ali os padrões eh de código de como nomenclatura por exemplo de como o código deve ser estruturado eh os padrões ali de namespace por exemplo para rotas de microsserviços se vai trabalhar com DDD ou não né
E aí se trabalhar com DDD como que vai ficar a rota ali das suas apis dos seus bffs Então tudo isso o arquiteto vai trazer em formato de guias para que o time de desenvolvimento consiga seguir e seguir de uma forma padronizada não fique uma bagunça cada um fazendo de um jeito e com isso o nosso time já consegue até mesmo começar a trabalhar mesmo que o arquiteto não tenha fechado todo o trabalho dele o time consegue seguir com trabalho de desenvolvimento Por quê ele já tem nas mãos os padrões que vão ser utilizados já
tem uma visão do que que é qualidade Então já dá para especificar ali o que a gente tem né Em cada interface como que vai ser ali cada módulo tá então a gente já consegue fazer todo um trabalho de especificação e de construção e esse trabalho de especificação tende a ser mais alto nível dando mais liberdade pro time de desenv movimento implementar ali usando logicamente a experiência de cada desenvolvedor né o que eles conhecem e dando Liberdade intelectual também para que eles criem para que eles façam parte desse processo criativo também ok então especificação ela
é importante mas ela é mais alto nível e mais linkada aqui Principalmente quando o arquiteto Faz esse trabalho é mais linkada aos padrões à práticas adotadas e aos porquês isso tem um link direto com as premissas que a gente levantou lá atrás V pisando mesmo eu posso começar a desenvolver mesmo sem ter ali todas as ferramentas escolhidas a Cloud que eu vou utilizar eh de repente o ferramental De Cash etc pode você trabalha com Abstrações tá bom e com Abstrações você consegue sair do outro lado nós temos também conteúdo sobre isso no nosso canal e
também vou deixar o link aqui tá para você assistir depois então com Abstrações você consegue seguir com seu trabalho de desenvolvimento sem nenhum problema tá bom bem E com isso a gente consegue postergar as decisões mais importantes a gente consegue empurrar um pouquinho mais pra frente e por que que eu faço isso essa é na verdade a nossa próxima caixinha aqui tá é o nosso próximo step o nosso quarto step é a a tomada de decisões por que que eu deixo ela para depois por que eu vou empurrando mais paraa frente porque com o passar
do do projeto com avançar do projeto novas histórias de usuário vão sendo criadas não é as pessoas que tomam as decisões vão tendo mais maturidade mais visão do que que é o produt aduto e isso ajuda a tomar as decisões de uma maneira mais acertada um pouquinho mais para frente né se você toma muito eh precocemente muito lá no começo essas decisões certamente você vai errar então o arquiteto ele precisa ter não só essas informações todas de premissas mas também ir entendendo o negócio e ir acompanhando a evolução dessa linha de raciocínio né no tocante
ao negócio a estratégia para que ele tome essas decisões posteriormente então aqui chegou o momento de começarmos a tomar as principais decisões escolher por exemplo a abordagem que trabalharemos né vamos supor que optemos por trabalhar com DDD né é uma abordagem arquitetural completa Ok então se optamos por DDD tem toda uma forma aqui de modelarmos o negócio de desenharmos o negócio se vamos trabalhar com cash ou não se vamos trabalhar com que tipo de modelo de dados né modelo consistente de consistência eventual de registro único então todas ess essas decisões elas vêm com base no
conhecimento que a gente veio tendo do negócio fomos entendendo do negócio né se vamos trabalhar ali com reatividade ou não preciso ter muita riqueza né uma experiência ali de ser rápido né mas de forma assíncrona ali com o nosso usuário né se eu preciso levar mais informações mais processamento lá pro device pra Ponta ou se eu deixo isso mais no meu server Side né então com base nas informações que a gente vai tendo com levantamento e com projeto que a gente vai desenhando a gente vai entendendo também e e conseguindo tomar essas decisões de uma
maneira mais acertada tá bom e por fim mas não menos importante depois que a gente já tem todo esse leque nas mãos né de informações os padrões que a gente vai utilizar o tipo de consistência e etc entra aqui a questão da estrutura e componentes tá o nosso quinto step aqui ele é o é o step onde eu tenho mais maturidade eu já tenho estruturas guias eu já tenho negócios desenvolvidos ali até at né soluções para negócios já desenvolvidas códigos já implementados padrões escolhidos né todas as premissas ali levantadas Então agora eu consigo também tomar
as decisões eh aquelas que são de certa maneira mais difíceis de serem revertidas por exemplo qual Database eu vou utilizar se eu escolho o Database errado que que acontece dificilmente depois eu consigo trocar porque imagina trocar asa do avião com avião Vando é quase impossível né Aí quando a gente tá falando dos componentes desenvolvidos é mais fácil mas a parte de dados não por quê eu tenho dados sendo imputados alterados excluídos o tempo todo e se eu tiver que trocar o Database a escolha do meu Database agora né depois de tudo isso já escolhido e
da aplicação funcionando talvez eu não consiga tão facilmente um processo ali de migração de um Database para outro pode ser pesado pode levar muito tempo pode requerer ali todo uma estratégia muitos testes e se a gente tiver um problema nisso daí talvez um HB seja também impossível né Talvez o HBC eu fiz a migração para um outro modelo de dados comecei a imputar dados ali dentro tá rodando a aplicação funcionando e começa a dar problemas bom aí é mais difícil ainda né porque imagina como que eu volto pra versão anterior eu tenho que levar os
dados novos para pro pro modelo de dados anterior pro banco anterior então fica tudo muito mais difícil tá algumas decisões aqui são praticamente impossíveis depois de serem e desfeitas muitas vezes a gente tem que literalmente jogar a aplicação toda fora e refazer então aqui que essas últimas decisões que são os componentes arquiteturais periféricos né todos que a gente vai ter ali ferramenta aud cche talvez a Claude que a gente vai escolher trabalhar né talvez eu ter que escolher a Claude lá no começo tá talvez não dê para puxar essa decisão pro final um exemplo disso
é se eu for trabalhar com serverless foi uma decisão e de projeto né de repente tomada até lá no comecinho do projeto e sendo serverless e talvez eu já faça lin com uma Cloud então já é uma decisão que eu tomei lá no começo Já nasci amarrado com uma Cloud uma WS por exemplo uma abraça né Então as outras decisões eu posso ir tomando depois o que eu conseguir empurrar mais pra frente é melhor tá principalmente dos componentes periféricos ali que vão atender né suportar a nossa arquitetura e olha só aqui nós falamos basicamente de
um dos tipos de atividade que um arquiteto de software faz tudo isso é importante né Principalmente a parte das premissas para os outros serviços de arquitetura que são a maioria né os projetos eles não são criados todos os dias e tem muito trabalho para um arquiteto no dia a dia não só com a parte de definição de um produto novo mas com a definição de um projeto novo com acompanhamento da evolução das premissas em função da própria solução que ela vai evoluindo né E quando a solução evolui as premissas também são alteradas o arquiteto precisa
estar antenado para ir alterando evoluindo essas premissas também e ir ajustando elas existem projetos que entram na na na nossa solução já desenvolvida e esses projetos eles precisam continuar fazendo com que as premissas sejam respeitadas então a figura do arquiteto mais uma vez aí é muito importante Tem a parte de validação de arquitetura Tem a parte de Visões Tem a parte de escala de manutenção até preventiva que o arquiteto consegue entrar ali e ajudar a identificar problemas né causa raiz de problemas então tem um universo de atividades muito grande com o arquiteto de software tem
para fazer nos projetos né E a gente não falou aqui nesse conteúdo e se você quer conhecer saber como funciona cada uma dessas atividades de arquitetura me conta aqui nos comentários que de acordo com a quantidade de comentários que a gente tiver aqui e de likes também vou pedir likes para você a gente faz esses conteúdos entendendo que esse tipo de conteúdo está fazendo sentido né a gente traz mais para você beleza e dessa forma eu vou ficando por aqui eu espero que você tenha curtido o conteúdo e como eu falei antes não esquece de
deixar um like para mim porque você é top demais e com certeza quer se tornar Fera em arquitetura e eu estou aqui para ajudar você nessa missão então capricha no like e eu vou ficando por aqui um super abraço até a próxima
