Como DEFINIR SUPER BEM a sua ARQUITETURA | FORMULA TOP | Arquitetura de SOFTWARE

fala aqui tudo certinho com você no conteúdo de hoje a gente vai falar sobre um tema extremamente importante na verdade fundamental para todo arquiteto seja ele iniciante ou com muitos anos de estrada que é definir uma arquitetura como definir uma arquitetura e fazer isso de uma forma top super bem fundamentada super bem elaborada e isso ar é importante porque tem duas formas de você definir uma arquitetura uma é se baseando em histórico profissional no que você já fez no passado no que você aprendeu no passado ou em coisas que você viu acontecendo em outros projetos

projetos dentro da mesma empresa ou no mercado essa é uma forma de você fazer ar e a outra é entrar no detalhe entrar a fundo mesmo nos requisitos de arquitetura para conseguir entender tudo direitinho e fundamentar cada decisão que você como arquiteto Vai tomar no projeto Então bora lá falar sobre [Música] isso ar antes da gente começar esse conteúdo eu gostaria de fazer um pequeno acordo com você Eu tô trazendo para você um conteúdo que é um compilado de vários os anos de experiência uma técnica que eu venho usando realmente e é efetiva ela não

só me deu vários resultados bacanas como eu vi várias pessoas que eu mentore aí durante a minha carreira aplicarem e também se darem muito bem com ela então o acordo que eu queria fazer com você é o seguinte se esse conteúdo te agregar muito valor se ele realmente fizer a diferença e fizer você mudar o teu minding set tua forma como definir arquiteturas Eu gostaria que você se inscrevesse no nosso canal caso você ainda não seja inscrito é lógico e se você for inscrito que você compartilhe ele com aquele amigão teu do peito que também

curte de arquitetura bacana acordo feito então bora pro conteúdo ar antes de mais nada é muito importante que você entenda o que é definir uma arquitetura e a resposta é bem simples Ok é direcionar todas as práticas os padrões as tecnologias os componentes arquiteturais que você vai utilizar na tua solução e esse direcionamento ele precisa ser muito forte ar ele precisa ser baseado eh nos requisitos de segurança né tudo que a sua empresa fala e pensa sobre segurança sobre infraestrutura né logicamente Você também precisa estar totalmente embasado né nas necessidades funcionais de negócio estratégicas de

governança né então pensando todas as leis com a área de dados comp com a sua área de dados com a área de dados da sua empresa Então o a tua definição o teu desenho ele precisa fazer essa ponte com todas as áreas para ser forte para ser embasado para que não seja facilmente derrubado ali com qualquer contraargumento e não só para isso né evidentemente o maior objetivo é valor agregado Afinal de contas você não vai fazer uma definição de arquitetura para colocar lá na gaveta você quer que ela seja aplicada que ela vá pra frente

que ela seja seguida pelo time que vai Construir aquela solução e etc e qual é o output né O entregável que você como arquiteto provê com base nessa definição de arquitetura toda são visões bacana E essas visões elas podem ser das mais variadas formas Depende muito da cultura da tua empresa né de quem vai e usar consumir esse artefato que você vai produzir ele ele pode ser desde um documento de arquitetura formal todo descrito né Cheio de informações como pode ser também desenhos feitos nas mais diversas notações por exemplo em uml em C4 em MDL

e até mesmo em Arch mate embora não seja muito o propósito dele você pode fazer pode usar sim o archimate também eu já vi é sendo aplicado e funcionando muito bem sem contar que para equipes extremamente ágeis ágeis Mesmo muitas vezes um desenho na lousa e uma foto desse desenho colocada ali depois no Google Keep ou em qualquer outro eh repositório de notas compartilhados ali logicamente com toda a equipe eh entra ali como uma parte né ou como eh a definição de Arquitetura do projeto Eu já vi isso acontecendo também e funcionou muito bem eram

times extremamente ágeis com cultura extremamente ágil e funcionou super bem e antes de a gente entrar no detalhe e eu te explicar exatamente como fazer uma definição de arquitetura a gente vai falar sobre os cinco objetivos de se fazer uma visão né uma visão arquitetural que é o resultado de um trabalho de arquitetura um trabalho de definição de arquitetura Então vamos a eles o primeiro e mais importante de todos é direcionar a construção de um produto um software que seja totalmente compliance com todas as necessidades corporativas envolvendo todas as áreas tá governança segurança infraestrutura dados

negócios né a parte da diretoria né a visão estratégica E claro também as necessidades técnicas muitas necessidades dos times técnicos muitas vezes estão ali no backlog de débitos técnicos né e muitas vezes você vai precisar trazer isso também e nessa definição de arquitetura Bacana Então o primeiro objetivo é esse direcionar a construção mas não só direcionar a construção de qualquer forma direcionar ela amarrando a todas as demais necessidades corporativas o segundo objetivo é ajudar em processos de trouble shooting quando dá ruim quando a aplicação começa a dar muito problema é muito comum que você recorra

ao mapa quando ele é bem feito bem estruturado bem fundamentado é muito comum que você olhe pro teu desenho para tentar identificar o ponto de origem né a causa a causa raiz dos problemas senão no momento inicial do tros shoting né que muitas vezes se vai realmente ali para métricas de infraestrutura etc depois no segundo momento na hora que você quer dar uma solução definitiva bacana o terceiro grande objetivo é na tomada de decisões estratégicas uma vez que você tem o desenho bem fundamentado tem todos os componentes arquiteturais né E se você tiver isso a

em larga escala né para todos os sistemas da sua empresa é muito comum que o arquiteto de sistemas ou então um arquiteto corporativo recorra aos mapas ali de cada produto desenvolvido para tentar entender Qual que é a dependência por exemplo de um grande componente arquitetural como o enterprise service bus ou um lightweight Gate a ou um banco de dados de repente uma Instância de banco quais são os produtos que estão usando ele então para tomar uma decisão ali de de repente desativar evoluir ou mudar de tecnologia né uma coisa que às vezes é muito grande

uma parceria você vai mudar de parceria eu vou deixar de ser sei lá parceiro Oracle para ser parceiro Microsoft ou IBM não importa tá E aí essa mudança é uma grande mudança de estratégia e essa visão que você criou normalmente é um mapa que vai ajudar e ajudar muito nessa tomada de decisões o quarto objetivo é auxiliar nos processos de escalabilidade uma vez que você tem tudo mapeado né Ark a visão ali de cada camadinha física camadinha lógica tecnologias que estão agregadas ali né que dão suporte para essa para esse desenho todo teu para esse

produto todo seu o que que você faz com tudo isso na mão você consegue identificar Aonde dá para escalar tendo uma Clara Visão de tecnologias e de tis né que estão em cada uma dessas tecnologias é muito fácil você começar a imaginar como que você pode escalar cada componente se você consegue escalar ele vertical horizontal né ou seja colocando mais máquinas ou aumentando o potencial daquela máquina daquele recurso de infraestrutura eh então ele te abre esses Horizontes e facilita também para você identificar Quais são os pontos de gargalo né uma vez que você de repente

Aumentou e em alguns pontos aqui imagina que esses aqui são microsserviços e você criou de repente sei lá um segundo contêiner com outros microsserviços Talvez o banco de dados aqui né Muito provavelmente na verdade vai ser único né mas ele não é o único componente esse daqui é óbvio né que você vai ter um banco único e dependendo da tecnologia desse banco aqui você só vai conseguir escalar ele verticalmente ou seja aumentando quantidade de memória aumentando quantidade de recursos computacionais então e isso aqui também né esse mapa de desenho ajuda você a olhar os demais

componentes que você teria aqui de repente você vai ter um Bet aqui que faz o quê que pega de repente informações do banco né E lança sei lá manda e-mails faz outras coisas aqui e talvez esse carinha aqui também vire um ponto de gargalo à medida que você vai começar a bombardear mais o banco de dados vai ter mais informações para esse carinha processar ele Talvez vire ali e mais um ponto de gargalo dentro do teu desenho como um todo então o mapa ele ajuda muito para você tomar esse tipo de decisão de escala também

e o último ponto mas não menos importante é que muitas empresas precisam de certificações por exemplo certificação cmmi certificações PCI né para você operar de repente eh no mercado financeiro tá armazenar al informações de transações financeiras e muitos desses certificados requerem que você tenha ali toda a sua arquitetura bem documentada e que ela seja exatamente compliance né o desenho seja um reflexo da realidade muito bem agora chegou a hora da gente falar sobre como fazer esse trabalho de definição de arquitetura e nessa metodologia que eu particularmente uso e trazendo para você a gente divide ela

em oito fases Ok a primeira del é o entendimento e não só entendimento de negócio a gente divide esse entendimento aqui em três Ok A primeira é visão estratégica e o que que é essa visão estratégica né é uma visão dos stakholders dos tomadores de decisão de repente do patrocinador do projeto de como que a empresa vai ter lucro com aquele projeto né uma grande visão de se esse é um projeto por exemplo para resolver uma dor um problema que algum cliente tem ou que a empresa tem um problema de performance uma lentidão ou se

é alguma coisa nova uma funcionalidade nova uma versão mobile e do que que se trata o projeto é algo novo ou é uma dor né mais do que isso como é que a empresa vê eh resultado com aquilo resultado financeiro mesmo como que ela vai monetizar aquele produto que tá sendo criado construído ou evoluído tá mais do que isso né uma visão ali de curto médio longo prazo como é que esses stakeholders enxergam essa plataforma né rodando em sei lá alguns meses depois que entrar em produção depois disso em alguns anos um 2 anos e

a longo prazo tem uma visão um planejamento para que seja long né Essa solução seja oniva dura ali 4 5 10 anos Qual é a expectativa desses stakeholders isso daí é importantíssimo para você começar o teu projeto né você já tem que pensar em alguma coisa fundamentada com base nisso o segundo ponto aqui tá é a visão funcional e aqui a gente tá falando do quê a gente tá falando de uma macrovisão de negócio para que que serve essa solução né Quais são as principais funcionalidades uma visão visão ali mais ou menos de quem são

os usuários uma visão mais abrangente do ponto de vista de negócio funcional tá E nesse momento ainda você não deve entrar muito no detalhe né Senão você vai perder muito tempo aqui mas é importante você entender fundamentalmente a as grandes funcionalidades né Para que que esse sistema vai servir né Que tipo de dor ou novidade ele tá trazendo entrar um pouquinho mais no detalhe né dessa grande visão né uma macrovisão entrar um pouquinho mais no detalhe né não é para você mergulhar no detalhe mas da macrovisão tá tem um macro entendimento do negócio como um

todo e por fim a gente tem aqui o levantamento de R o que que são ra ra são os requisitos de arquitetura ou seja todas as coisas que impactam direta ou indiretamente nas suas decisões arquiteturais na sua definição de arquitetura eh Com certeza aqui e aqui você já levantou alguns ras você já tem alguns aqui na mão eh só por esse bate-papo só por esses alinhamentos aqui mas aqui você entra em todos os rnfs né que são os requisitos não funcionais tá um ra no final das contas ele é um conjunto né de todos os

rnfs mais os RFS que impactam ali diretamente no teu desenho exemplo eu preciso manter eh o extrato de de um cliente por 5 10 anos eu ter que manter ele na minha base e de repente Ok de ser um pouquinho mais lento eh depois de TRS meses demorar um pouquinho para carregar ou ter um outro processo Esso para carregar mas eu preciso armazenar por 10 anos então é um requisito funcional percebe que vai ter um impacto no desenho eu vou ter que pensar aqui em formas de manter muitos dados e de repente dados pesados aí

por muito tempo por 10 anos tá tem que pensar em tudo backup etc e a gente pode ter aqui vários outros tipos de requisitos tá legais por exemplo poderia ter aqui que tem que ser Complex com lgpd né de segurança de infra E por aí vai você pode ter vários requisitos aqui que vão impactar no teu desenho de repente Ah eu já tenho uma parceria x com empresa x eu não posso fugir dela Sei lá eu sou parceiro Oracle então tudo que eu vou fazer dentro da minha companhia tem que mais ou menos cair ali

pro mundo Oracle Database Oracle enfim barramento de serviço da oraco eh tecnologia de repente de desenvolvimento Java Então já tem algumas premissas aqui que precisam ser seguidas Então tudo isso você vai levantar aqui nesse momento tá na fase um Nossa aqui é o entendimento de tudo o entendimento do teu cenário como um todo beleza e a gente não vai falar de cada uma das perguntas que você faria aí para cada área porque isso daqui é praticamente um módulo inteiro de um curso a gente tem isso lá no ar expert e eu falo para você que

é um dos maiores módulos que a gente tem nesse conteúdo bom e eu falo para você que tudo daqui paraa frente vai ser baseado nesse carinha aqui tá tudo vai tem que seguir aqui essa fundamentação toda eh porque senão né O que você vai acabar tendo vai ser uma definição voltada a opiniões Ok não vai ser voltada a necessidades reais da sua companhia e isso vai fazer com que rapidamente a sua arquitetura que é uma arquitetura nova um desenho novo uma definição nova passe a ser uma definição de arquitetura antiga legada né rapidamente com pouquíssimo

tempo e aí a gente acaba caindo na velha história da arquitetura nova que Inclusive a gente tem um conteúdo no canal falando sobre isso vou deixar aqui no card para você assistir depois desse conteúdo bacana Ark legal agora pra gente falar da segunda V colocar isso aqui numa pequena pirâmide aqui tá então primeiro antes de mais nada a gente tem aqui a parte de fundamentos né que é o que a gente acabou de falar aqui entendimento geral da solução estratégico de negócio entendimento de ras né a segunda coisa que a gente precisa definir aqui é

o modelo arquitetural beleza e o que que é esse modelo arquitetural é uma grande visão de segmentação tá bom tipicamente a gente tem aqui né eh monolitos tá a gente tem né modelos que são semim monolíticos e a gente tem modelos que são totalmente micro componentizar tá eh e aí a gente pode falar aqui né de monolito é o que você tem ali um grande um um grande quadradinho né um grande bloco de códigos ali um grande executável uma grande dll né É e tem aplicações que são semim monolíticas tá que elas são ali por

exemplo as distribuídas né você tem várias vários componentes distribuídos na sua infraestrutura mas são componentes segmentados né monolito monolito monolito mesmo é de repente ali uma aplicação feita em cobol é de repente ali um Bet que fica enviando e-mail né bets normalmente são monolíticos né muitos bets que eu conheço são monolíticos então Eh Isso é uma arquitetura monolítica semim monolítica De repente é uma camada só que você tem ali sei lá de repente você tem microsserviços no teu Core mas todo o restante da sua aplicação é monolítica então você tem um Fronte monolítico um banco

monolítico um monte de componentes monolíticos então não dá para você dizer que a sua arquitetura é totalmente microcomponente tizada né ela pode ser orientada a microservices bacana mas ser orientada a microservices não faz dela uma aplicação microcomponente faz dela uma aplicação semim monolítica tá bom e Então essa é uma visão que é importante você ter aqui na hora de definir o modelo arquitetural é e assim é muito importante que você entenda né que quanto mais para cá você vem né mais complexo vai ser o teu modelo mais complexo vai ser o seu desenho de mais

componentes de suporte de cach de log etc você vai precisar ter e mais difícil vai ser você evoluir manter mais caro vai ser a a tua infraestrutura tá bom e quanto mais para cá você tiver né mais barato Isso aqui vai ficar tá bom eh menos custo você vai ter em geral aqui tanto para fazer para manter para evoluir etc mas você tem né Sempre tem tudo tem prós e contras né mas para cima você tem menos disponibilidade menos flexibilidade entregar um pequeno componente vai demorar mais testar vai ser mais complicado você não vai conseguir

testar cada pedacinho você vai ter que testar um todo né Vai ter muito acoplamento mas são modelos é que funcionam e que tem prós e contras é importante você né sempre se basear em prós e contras senão você vai voltar naquele ponto né onde sua arquitetura vai ficar obsoleta muito rápido a terceira Grande Decisão sua aqui tá é escolher as abordagens Ok e aqui a gente tá falando de abordagens de desenvolvimento e abordagens arquiteturais tá falando das duas coisas todas as abordagens que você vai usar a abordagem ela é um minding setet completo Tá bom

ela é uma metodologia de você fazer um link de repente com as necessidades funcionais ali né o pessoal de negócio trouxe para você o que para quem por né n Ele trouxe o que pra gente e a área técnica né em específico a arquitetura vai falar o como bacana E esse Elo das duas coisas acaba sendo a abordagem ela precisa ser coerente bacana precisa ser coerente com o teu negócio né com a visão Como que o negócio segmenta eh as funcionalidades da empresa por exemplo ah segmento em módulos então talvez seja seja interessante você partir

para uma abordagem modular você vai começar a pensar em tudo de forma modular tá bom ah eles pensam em domínios Opa bacana de repente a gente pode pensar em DDD né começar a segmentar tudo em domínios então entenda aqui a gente não tá falando do padrão arquitetural de como que a gente desenha a gente tá falando ainda de uma visão sobre como a gente vai estruturar como que a gente vai segmentar em cima dessa visão aqui né em cima do modelo arquitetural como que a gente vai segmentar eh o negócio tá bom como que a

gente vai quebrar o negócio aqui dentro dentro dessas dessas grandes caixinhas né eu vou ter um módulo x o módulo Y módulo módulo de cadastro módulo de cliente Ou eu vou ter um domínio né ou então o que que eu vou ter Tá bom vou ter um componente que representa esse cara que que eu vou ter é um evento Tá bom então é é isso que a gente vai definir aqui ok aqui realmente entram todas as abordagens tá você pode colocar aqui de repente tdd bdd né que são metodologias de teste né E pode ter

o DDD né que é domain drive and design pode ter arquitetura exagonal orientação a eventos ou então orientação a objetos né que às vezes você casa mais de uma coisa tá tudo bem também de casar mais de uma coisa por exemplo é praticamente impossível você ter DDD sem ter orientação a objetos você não vai fazer isso em orientação a eventos por exemplo vai ficar estranho tá bom Arc então Eh percebe é uma escadinha é é uma coisa aqui que reforça a outra tá bom É tudo fundamentado sua abordagem aqui é coerente com o teu modelo

arquitetural que é aderente a todos os fundamentos que Você levantou aqui de negócio estratégico e etc o quarto ponto são os padrões de arquitetura tá E aí sim a gente tá falando de como vai ser estruturada a aplicação das camadas que essa aplicação vai ter em cada caixinha dessa daqui tá bom então você já tem aqui a forma como você vai transcrever tudo agora chegou a hora de você tangibilizar esse negócio todo então por exemplo se você tá trabalhando com DDD né você já falou que você vai usar essa abordagem aqui tipicamente Você vai desenhar

é usando o padrão arquitetural que o DDD traz também que é a segmentação em camadas proposta pelo DDD tá bom que é a camada de infraestrutura de aplicação de domínios dentro de domínios toda aquela visão de raiz de agregação seus domínios propriamente dito ali né as entidades os Val e Object Ok então é de acordo com essa abordagem que você vai escolher o padrão e tem vários tá tem o mvc mvvm MVP isso são padrões arquiteturais padrões arquiteturais são formas de segmentar a tua aplicação Como que você quebra a tua aplicação são as camadas e

as responsabilidades de cada camada isso é um padrão arquitetural Inclusive a gente tem um conteúdo no canal falando sobre e segmentação em n Tears eu vou deixar aqui no no card para você assistir depois também a Quinta Etapa é a definição das suas tecnologias tá então de novo ó percebe a nossa escadinha aqui né agora que eu já tenho tudo isso fundamentado chegou a hora de eu falar das tecnologias que é a linguagem de programação de repente que eu vou usar nesse cara todo aqui né os os two kits os frameworks e a tecnologia de

armazenamento de dados né se vai ser relacional ou não relacional Qual tecnologia eu vou usar qual Linux eu vou usar né coisas relacionadas a devops então por exemplo qual que vai ser o meu ferramental de de CCD de continuous monitoring eh essas coisas todas você levanta aqui tá a gente não tá falando de componentes arquiteturais a gente tá falando das tecnologias para construção para desenvolver bacana bom o próximo que vem aqui em cima praticamente no topo né Aí sim são os componentes arquiteturais tá que que são componentes arquiteturais é o que vai dar suporte a

tudo isso aqui eh por exemplo para pra solução sua funcionar né você vai Talvez precisar de um orquestrador de contêiners então o kubernetes é um componente arquitetural você vai usar de repente um ferramental de log que ferramental de log que você vai usar vai usar o Grey log vai usar o o o kibana com elastic search né O que que você vai usar de de de ferramental aqui todo seu ferramental todo o teu rabol tá ferramenta de Cash ferramenta de identity provider Enfim tudo que você vai precisar para suportar o teu desenho É nesse momento

aqui que você eh faz essas escolhas Ok é essa escadinha aqui tá não adianta você sair fazendo o contrário senão você vai acabar inferindo em vários contrapontos aqui por exemplo você pode ter um requisito aqui que essa aplicação ela tem que ser extremamente rápida rápida mas por um volume pequeno de usuários então talvez já não faça sentido você sair pensando em em estruturar esse negócio aqui no modelo arquitetural e microcomponente zado muito provavelmente você vai ter que cair ou para semim monolítico ou para monolítico né você vai ter que ir mais para essa linha porque

eu tenho pouquinhos usuários conectados né é um volume baixo de repente eu tenho aqui pouca grana para gastar com infraestrutura E aí você vai para modelo que que vai custar mais caro que você vai precisar de mais componentes de mais infraestrutura ou você vai para modelo mais simples é aí que mora a coisa toda Tá bom então você vai ter que pensar nisso aqui antes de você chegar aqui em cima é isso que a gente tá falando uma coisa vai te levando aqui a outra o sétimo ponto né a sétima coisa que a gente precisa

fazer é Finalmente uma visão tá uma visão de tudo isso daqui então agora que você já tem tudo fundamentado você tem o modelo arquitetural as abordagens os padrões as tecnologias os componentes arquiteturais que você vai usar chegou a hora efetivamente antes de você desenhar esse cara E aí que você vai usar ou o ML né ou o C4 ou MDL ou até mesmo archimate como a gente já falou para construir Essa visão tá com o máximo de e detalhes possível é legal que esse que esse desenho que esse diagrama ele ele siga ali eh um

um padrão formato que seja agradável né que engaje a pessoa que vai ler se for bagunçado Ark Se for muito bagunçadas percebe a quantidade de informações que a gente tem aqui se esse negócio não não for casado não tiver uma sequência não for fácil FC de ler que que vai acontecer né ar a pessoa que vai ler isso daqui os times que vão ler o time técnico que vai ler ou qualquer outro que vá usar esse documento não vai se engajar talvez não consegir entender fique confuso para ele então vou deixar aqui no card um

conteúdo que a gente fez já aqui pro canal que vai ajudar você a fazer esse tipo de desenho né de forma que engaje as pessoas a gente usou nele né nesse exemplo anotação MDL que é a minha favorita né hoje em dia eu praticamente Só uso ela então eu recomendo que você depois desse conteúdo clique lá também e assista Tá bom vou deixar nas descrições do vídeo também para facilitar para você e a última etapa mas não menos importante é você apresentar Essa visão aqui pros seus companheiros todo mundo que vai estar envolvido na construção

desse produto ou serviço não importa eh vai precisar entender né Qual foi o seu racional entender de forma bem clara bem objetiva porque que você tomou cada decisão que você tomou né que você materializou ali nessa visão E aí eu te falo que tipicamente né o a gente tá muito na moda fazer meetup eu acho muito legal tá é é uma reunião informal muitas vezes com a galera toda de pé junta ali De repente num pequeno auditório ou numa área ali onde o pessoal vai para tomar café pega todo mundo ali de pé mesmo e

Abre ali a sua máquina e mostra o que você fez mostra sua visão explica apresenta o porquê de cada decisão ou então pode ser sim no modelo mais formal isso funciona também de repente para uma sala de reunião e apresentar tudo bonitinho tá então Independente de como isso aconteça é importante que isso aconteça para que as pessoas né né todas as envolvidas das outras áreas também de governança de infraestrutura de marketing etc entenda o o que que você tá desenhando Por que você tá desenhando e mais do que isso para que elas vejam que elas

fazem parte desse desenho é legal você mencionar Olha a gente fez isso por causa da área de marketing que passou pra gente Tais informações e tudo mais esse identity provider aqui a gente usou para ser comp com segurança e tudo mais é uma boa hora também para você pegar feedback né ouvir ali a as outras falando Opa isso aqui não ficou legal isso aqui ficou bacana isso ficou ruim né é uma ótima hora para você eh conseguir efetivamente fazer ajustes no seu desenho e ajustes Com base no que as pessoas estão falando então elas vão

acabar ajudando você a finalizar esse desenho e olha o nível de engajamento que você tá levando né você tá fazendo com que as pessoas né todas as pessoas de todas as áreas participem ativamente na construção do teu desenho isso é muito forte Ark isso faz com que todo mundo se engaje no teu desenho na tua definição e percebe mais uma ver se você se basear Numa pesquisa do Google uma arquitetura usando DDD arquitetura exagonal Botou ali no Google vai ver um monte de desenho pronto você pegar aquele desenho pronto e botar ali no teu PPT

isso não é arquitetura Arc tá é isso daí não vai engajar ninguém Isso daí não vai ajudar ninguém a resolver nada então é muito importante que você faça primeiro isso aqui ó essa aqui é a base de tudo se você não tiver fundamentação um abraço todo o resto não pare de pé tá vai ser uma aplicação que vai durar pouco tempo né vai ter uma longevidade pequena vai nascer já com um monte de débitos técnicos não atendendo ali os anseios dos stakeholders então ar é realmente muito importante começar por aqui tá levantar ra é chato

é difícil é maçante mas é importante tá bom é o fundamento é a base então ar esse aqui é praticamente o Framework é uma receita de bolo para que você consiga fazer assim como eu faço definições de arquitetura e definições de arquitetura muito assertivas bacana por quê Porque você vai olhar para prós e contras de cada uma das coisas que você vai olhar aqui e vai fazer todo esse casamento né do Ra a tua definição a tua visão que você vai entregar legal ar se esse conteúdo fez sentido para você então não esquece de deixar

aquele like Maroto Pra gente para incentivar a gente a continuar produzindo conteúdo desse tipo para você abraço ar até a próxima