Bom pessoal, agora a gente vai falar um pouco sobre as estruturas que normalmente fazem parte na hora que você vai arquitetar uma aplicação. Se na hora que você for arquitetar essa aplicação você conseguir olhar bem para essas estruturas, você vai ver que vai ser muito mais leve você trabalhar com software. Quais são essas estruturas? Vamos lá. Componente conector. O que isso significa? Como que eu tenho componentes e como esses componentes conseguem falar um com os outros. Segundo passo, módulos. Entenda que módulo é diferente de componente. O módulo vai agregar o comportamento interno da sua aplicação e separar uma área que faz sentido estar junto para gerar valor. Agora, como esses módulos podem se tornar componentes e como esses componentes conseguem se conversar, eles fazem parte de uma outra parte estrutural, que é a parte componente-conector. Legal? E por último, a gente tem a estrutura de alocação. E essa estrutura de alocação, você vai perceber que ela tem a ver de o que a gente vai utilizar para manter o software funcionando. Desde um tipo de disco, desde um tipo de processador, desde um tipo de banco de dados, desde um tipo de qualquer coisa que faça sentido para suportar a sua aplicação. coisa que faça sentido para suportar sua aplicação eu sei que falar disso apenas é mostrando três bloquinhos pra vocês a possa aparecer algo um pouco mais superficial então eu queria um pouquinho mais a fundo aqui, porque isso é o que vai fazer muita diferença para você conseguir entender como trabalhar com arquitetura de software. Aqui, espera um pouquinho. Aqui, tá? E eu quero que você olhe aqui, essa nossa parte aqui, arquitetura de software. Então, se você olhar aqui, deixa eu tentar colocar um pouquinho mais de zoom aqui para você ver melhor. Então, olha só. Componente, conector, módulos e alocações. Toda vez que você for arquitetar alguma coisa, você vai pensar, quais são os componentes e conectores que vão fazer isso funcionar? Quais são os módulos que eu preciso? Quais são as alocações que eu preciso? Olha só, galera. A parte que eu acho que é mais complexa de tudo, em qualquer tarefa que você vá fazer na sua vida é um método quando você não tem método quando você não estrutura algo tudo parece prioridade tudo parece ter o mesmo peso e tudo aparece ao mesmo tempo quando você estrutura algo, quando você tem um método de ver alguma coisa por mais simples ou rebuscado que seja esse método você sempre vai ter um ponto de partida então olha só que interessante o que que eu tô mostrando aqui para você é um ponto de partida na hora que você for pensar na arquitetura do seu software e agora nessa aula em específico eu quero falar do que para você do componente conector, que é um dos pontos mais importantes e que a gente sabe, mas a gente não olha de forma intencional. Muito do que eu vou te mostrar aqui é óbvio, mas agora a gente vai pensar de forma intencional. E quando a gente pensa isso de forma intencional, você já começa a expandir a sua visão na hora que você for falar sobre algum software legal então olha só componente conector olha só que interessante eu estou mostrando aqui pra você um cliente que tem serviços tem serviço que fala um banco de dados serviço que trabalha aqui numa pub sub serviços que jogam dados num bucket, que acessam um banco de dados e tudo mais agora, o que isso tem a ver com o que a gente acaba colocando se você pensar quando eu estou olhando o meu client o client é um componente que interage com alguma coisa o meu client pode interagir com o meu core, com o meu serviço A, com o meu serviço B. E ele pode interagir de diversas formas. Então perceba que aqui eu tenho os componentes. Agora, como que esses caras interagem? Eles interagem através de conectores. E são esses conectores que a gente tem que aprender a trabalhar com eles, para cada vez ficar mais simples você adicionar meios de comunicação entre esses componentes. Quanto mais fácil é você se comunicar de um componente para o outro, mais fácil fica a arquitetura do seu sistema. Legal? Então, entenda aqui que cada bolinha dessa aqui, seja, de forma geral, um conector. E um conector precisa falar a língua de outro. Legal? Agora, nossa Wesley, que negócio óbvio. É óbvio. Mas olha só que interessante. Qual foi a última vez que você desenhou uma arquitetura mais ou menos desse tipo, definiu todos os componentes e todos os conectores e como cada conector desse funciona? É óbvio, mas nem sempre você faz isso. Você faz isso de forma empírica. Você vai desenvolvendo, vai desenvolvendo, as coisas vão se comunicando, mas você não pensa de forma intencional. E quando você não pensa de forma intencional, é aquela história, se você não sabe para o caminho que você vai, qualquer um vale. Se eu não penso de forma intencional aquela história se você não sabe o caminho que vai qualquer um vale eu não penso de forma intencional às vezes esse conector falar e era um martelo e um parafuso né então olha só que interessante então todas as vezes que você for levantar a estrutura de um software você vai pensar em quais são os componentes desse software, quais são os conectores desse software. Independente se isso é uma arquitetura distribuída ou não. Isso aí é importante você se ligar. Agora, olha só como a gente anda e anda, a gente sempre acaba caindo no mesmo lugar. Olha só que interessante. Vou descer aqui para você. E alguém aqui já ouviu falar em arquitetura hexagonal é criada pelo lstar coburn olha só que interessante arquitetura hexagonal ou porto na data o que ela prega aqui né ela prega que cada parte do hexágono é uma porta de conexão. E essa porta, quer dizer, essa porta tem um adaptador que consegue falar com o mundo externo. Então, se você olhar, que coisa interessante aqui, você vai ver que eu tenho cada cara desse aqui que eu vou me conectar eu vou me conectar para falar com componente é mas para esse meu componente funcionar eu preciso de conectores então eu tenho um user que pode ser com GRPC. Eu posso ter aqui esse meu componente que vai falar com o mundo externo para salvar dados num banco de dados, ou jogar um PDF num bucket da S3, sei lá, não interessa. Então, se você começa a perceber, a gente começa a pensar no que? Componente, conector. E, novamente, olha só que interessante, a gente começa a pensar no quê? Componente, conector. E, novamente, olha só que interessante, a gente não falou que a arquitetura de software, muitas vezes, ela tem que ser lembrada por os atributos públicos que ela acaba proporcionando para o restante da arquitetura dos outros seus sistemas dos outros componentes se você perceber aqui na arquitetura hexagonal ele tá falando os caras externos estão falando apenas com os atributos públicos porque porque o resto está dentro do meio da aplicação e aqui essa parte que o alistar coban Cobain lava as mãos e fala. Não me importa como vai ser desenvolvido o meio do sistema. O que me importa é como os outros sistemas vão se falar para chegar no meio do sistema. E por isso que eu crio adaptadores e portas para falarem com o meu sistema. Agora, o que acontece lá dentro? Dane-se. Por quê? Porque são componentes privados. Entende? Então, olha só que interessante como as coisas vão andando. E olha só que interessante também aqui. Aqui a gente tem um padrão muito conhecido, a gente já falou sobre isso. ACL, Anti-Corruption Layer. O que esse cara faz no final das contas? Imagina que eu tenho uma aplicação que tem um conector que fala com um meio de pagamento. Agora, se eu quiser falar com vários meios de pagamento, o que eu faço? Eu posso criar um conector que fala com um cara especializado em falar com gates de pagamento esse cara aqui vai conseguir falar com esses protocolos com essa linguagem diferente mas a minha aplicação ela vai ficar preocupada em falar apenas uma língua então se você começar a perceber tudo que a gente faz, quando a gente está arquitetando um software, é falar de componente e conector. Se você começar a definir o que é componente, o que é conector, o que eu vou precisar e como que esses caras vão falar, no final do dia, a sua aplicação ela vai estar muito, mas muito mais estruturada. Então, você pega arquitetura hexagonal, você pega camadas anticorrupção, você pega qualquer coisa que a gente vai conseguir abstrair, você simplesmente está falando de arquitetura. Lembra? Arquitetura é uma abstração. Se você está conseguindo tomar decisões que você abstrai para conseguir expandir o seu software, necessariamente você está tomando decisões de arquitetura de software. Legal? É isso aí.