Bom pessoal, agora chegou a hora de a gente falar sobre estrutura de módulos. O que isso significa no final das contas? Lembra que eu falei para vocês? Quando você olha para a arquitetura, você pode dividir isso aí, dividir o olhar para a arquitetura nessas três partes. Então, qual é a diferença de componentes e módulos? Como que isso aí acaba funcionando então quando a gente pensa em módulo a gente pensa em unidade de software tá invariavelmente né um módulo pode ter componentes ali dentro deles não necessariamente você vai ter um módulo é igual a um componente eu posso ter um módulo com diversos componentes ali dentro. Legal? Quando a gente está falando em módulos, a gente pode estar falando dos pacotes do nosso sistema, a gente pode estar falando das responsabilidades que o sistema vai ter. Legal? Então eu posso ter realmente módulos no meu sistema que trabalhem com a parte de checkout, eu posso ter módulos que trabalhem com a área de recomendação legal então isso aí não tem problema você tem que conseguir ter uma visão diferente do seu sistema não compor não através de componentes mais por modo legal as camadas da sua aplicação né elas também podem ser divididas de forma modular. Legal? Quando você está olhando para módulos, você vai estar olhando para uma visão mais micro. Então, quando você olha componente, conector, você consegue ter aquela visão geral do que está acontecendo e como as coisas se comunicam. Quando você está olhando para os módulos, você já coloca uma lupa e começa a ter detalhamentos muitas vezes inclusive desses componentes tá então entendimento dos módulos vai fazer com que você olhe entenda como que as classes elas se encaixam como que elas vão ter abstrações para falar com outras classes e pontos desse tipo. Legal? Vamos dar uma olhada aqui rapidamente, tá? Num exemplo que eu inclusive tirei do livro, de forma geral de referência, que eu vou colocar aqui para vocês, tá? Mas olha só que interessante quando a gente está falando aqui em estrutura de módulos tá então quando estou falando em módulos eu posso estar falando aqui num pacote tá eu posso estar falando numa classe eu posso estar falando em né a uma classe que consegue no final das contas acessar atributos e realizar operações. Eu consigo falar de classes abstratas, eu consigo criar interfaces e eu consigo também trabalhar com mais detalhes para a gente conseguir utilizar todo esse conjunto de recursos. Quando eu estou falando de módulos, eu também posso estar falando em como que esses módulos são organizados. Então, se você perceber, aqui invariavelmente você tem seus pacotes, mas de uma forma ou de outra, dá para perceber que você tem um pacote, que aqui você tem camadas, e essas camadas aqui e pedaços vão conseguir trabalhar com isso. E esses pedaços fazem relação como que elas vão trabalhar aqui para a gente. Então perceba, aqui você já está numa visão, mas você está dando basicamente um drill down ali na sua aplicação. Beleza? Aqui está a referência de onde são essas imagens aqui para vocês. Legal? Então, o que acontece? Toda vez que você vai trabalhar com módulos, qual é a vantagem de você ter essa visão? Eu acho que esse é o ponto. Não é eu chegar aqui para vocês e falar, isso aqui é módulo, e você falar, ok, é módulo, beleza. Não, toda vez que você estrutura uma arquitetura, essa arquitetura, como diz o Uncle Bob, tem muita gente que gosta dele, tem gente que não gosta tanto, mas de uma forma geral, ele fala uma coisa que pelo menos pra mim faz muito sentido o banco bob ele fala de um termo chamado de scream arquitetura tá ou seja uma arquitetura que grita o que isso significa galera significa que quando você olha o sistema somente de você olhar a arquitetura você entende o que o sistema faz e os seus principais comportamentos. Então, quando você organiza a estrutura, a arquitetura da sua aplicação e você entende os conectores, os componentes, e você olha para os seus módulos, esse olhar tem que responder perguntas que vão te ajudar a refletir como que esse sistema vai durar ao longo prazo e como que esse sistema vai se comportar de acordo com os requisitos funcionais e não funcionais da sua aplicação. Legal? Deixa eu só beber uma água aqui, galera. Então, olha só. Quando você olhar para os módulos dos seus sistemas, esses módulos vão te ajudar a fazer algumas perguntas que se você souber responder, você com certeza vai estar mais preparado para conseguir desenvolver esse sistema com mais assertividade. Então, quais são perguntas intencionais que a gente pode fazer em relação a módulos aqui tá algumas dessas perguntas vem de referência de livre algumas perguntas que eu normalmente faço tá qual é a principal responsabilidade de cada modo tá só olha aquele modo você vai falar o que realmente esse módulo faz nossa uefa mas que pergunta óbvia não é óbvio porque quando você vê módulos com muitas responsabilidades isso significa que você vai lutar contra algo que é o maior mal de qualquer tipo de arquitetura, que é o acoplamento. Da mesma forma que quando a gente fala de economia, um dos piores maus que uma economia quebrada pode trazer é a inflação, acoplamento é a pior coisa que pode acontecer numa arquitetura. No final do dia, quando você faz uma arquitetura ruim, porque existem arquiteturas ruins, o que acontece? Você vai perceber que grande parte da dificuldade de você trabalhar com aquele tipo de arquitetura é o acoplamento. Então, quando você olha para aquele módulo e começa a perceber que aquele módulo começa a ter responsabilidades muito diferentes, aquele módulo começa a se mudar por razões muito diferentes. A gente pode até fazer uma analogia aqui com o S do Solid. O que isso acaba significando? É uma red flag e aí talvez você, talvez vale a pena você segregar esse tipo de módulo. Viu como uma simples pergunta pode mudar completamente tudo? Quais elementos de software cada módulo acaba utilizando? Quando a gente está falando de software a gente pode estar falando de bibliotecas a gente pode estar falando de frameworks a gente pode falar tá falando de conexões externas a gente pode falar de muita coisa então quando a gente sabe o que aquele módulo utiliza você vai entender o impacto que a arquitetura bem feita vai fazer naquele software. Porque se ele estiver se comunicando de forma inapropriada, se ele estiver utilizando outros modos, dependências muito fortes, etc., você vai ver que você vai ter um software ainda assim muito acoplado. O que realmente o software faz e do que ele depende? Olha só aqui, galera. Lembra que eu falei da arquitetura que grita? Se você olhar para um módulo e aquele módulo não fizer aquilo que ele tem que parecer que ele faz, significa que alguma coisa está errada. Ou você está tendo responsabilidade mais ou você está com aquele módulo no lugar errado daquele sistema quando alguém olhar para sua arquitetura você vai perceber que as coisas têm que se encaixar as coisas têm que fazer sentido de uma forma muito simples está uma das coisas que eu mais me esforço, galera, e eu comecei a perceber que quanto mais tempo de carreira eu tenho, o que eu mais faço, que eu acredito que é o mais difícil, é você deixar o seu software simples. A grande diferença de um bom desenvolvedor para um desenvolvedor que não tem, como que eu posso dizer, cuidado com o seu código, é que o grande desenvolvedor, o bom desenvolvedor, é o desenvolvedor que consegue simplificar. É o desenvolvedor que consegue mostrar o código e todo mundo consegue entender o que esse código faz. Existem desenvolvedores que adoram complexidade adoram falar poxa usando estou usando aquilo e no final das contas tudo acaba sendo mais complexo então quando você consegue fazer uma linha de dependências tá entender como cada módulo depende de outro, você começa a olhar também aonde essas dependências podem gerar um forte acoplamento e você pode tentar mitigar isso. Galera, acoplamento acontece. Não dá para fazer um software 100% desacoplado, porém você pode minimizar isso. E entender uma árvore de dependências vai fazer muito a diferença. E uma outra coisa aqui é, eu já falei de acoplamento, mas eu acho que vale mais uma pitada aqui para você se ligar de uma coisa. Qual é o nível de acoplamento de módulos, classes e etc? Quando a gente está falando de acoplamento eu não só estou dizendo que uma coisa depende da outra porque uma coisa depender da outra é comum você tem dependências agora a diferença entre uma dependência em um acoplamento é que se um módulo mudar, o outro vai ter que mudar. De uma forma muito drástica. Se você precisar refaturar alguma coisa, você tem um risco muito grande de afetar outros pedaços. E o mais importante de tudo, se você quiser substituir aquela dependência por outra dependência, e isso for muito difícil de você fazer, provavelmente é porque o seu acoplamento está muito forte. Entende? Agora, a gente vai falar, inclusive, um pouquinho mais para frente, é como que eu consigo evitar de tentar sair criando abstrações e mais abstrações em toda a minha aplicação, dificultando a forma de como que eu vou dar manutenção ou fazendo o meu código ficar muito verboso para evitar esse tipo de acoplamento. É difícil de a gente dosar isso, galera. Mas a gente vai entender isso também nos próximos vídeos. O grande ponto que eu quero que você entenda hoje é como que eu consigo medir o nível de acoplamento. Dê notas. 1, 2 e 3. Você olha para os seus módulos e fala esse módulo depende desse. Qual o nível de acoplamento? 1. Significa que eu tenho uma abstração que eu posso fazer com que esse módulo consiga ser intercambiável, por exemplo. Dois, significa que eu tenho um pouco de trabalho, mas ainda assim eu consigo intercambiar. Eu vou ter que quebrar interfaces, eu vou ter que quebrar contratos, mas o que acontece? Mesmo assim eu consigo intercambiar. E três, é o pior tipo de acoplamento, porque você não quebra apenas contratos para falar com outros módulos, você tem que redesenvolver parte do seu software para se adequar a outro módulo. Então olhe bem o acoplamento crie um mapa para você olhar e coloque 123 some este nível de acoplamento né e veja uma tabela e você baseado nessa tabela você vai conseguir entender né como que o seu software ele vai se comportar e o quanto de red flags que você pode ter no meio desse ponto. Legal? Show de bola, pessoal! Então, falamos um pouco sobre módulos e as perguntas que você tem que fazer quando você olha para os seus módulos. Perceba, galera, tudo isso que eu estou falando para vocês é fundamento. Tem gente que gosta de ver código, mão na massa, etc eu sei disso, eu também gosto mas o que vai te diferenciar de outros desenvolvedores não é só o quanto você programa bem em uma certa linguagem, é quais são as perguntas certas que eu tenho que fazer quando eu olho pro meu sistema porque isso vai influenciar se o sistema vai ter sucesso ou não. Beleza? E essas perguntas vão te ajudar bastante nessa jornada. Um grande abraço e vamos lá para o nosso próximo ponto.