Vamos Falar Sobre Arquitetura Limpa?

hoje o conteúdo está irado mas antes de seguir para o vídeo Eu tenho um convite super especial para fazer para vocês no dia 2 a 4 de outubro a gente vai fazer um evento ao vivo online e gratuito e objetivo desse evento é transformar a forma como você desenvolve aplicações como abordagem única no mercado Nós vamos te mostrar como você pode parar e deixar de escrever código anêmico e fraco e passar a construir de fato aplicações fortes aplicações que realmente podem te valorizar E vão te valorizar no mercado como desenvolvedor e para participar é super

simples basta clicar no link abaixo aqui na descrição e já garantir a sua vaga eu não tenho dúvida que esse evento pode mudar a tua história como programador a gente vai falar sobre modelagem rica eu vou te ensinar onde e como desenvolver as regras de negócio nós vamos falar de casos de uso testes princípio da inversão de dependência que é um princípio de online extremamente importante no princípio que pode salvar a tua aplicação separando as regras de Framework de infraestrutura Mas vamos falar de encapsulamento arquitetural e ainda vou te mostrar como integrar tudo isso de

forma saudável com os principais frameworks de mercado Então se inscreve não perde essa chance a gente se vê lá então a ideia do vídeo de hoje é entender essa figura aqui que é a figura central da arquitetura limpa e no próximo vídeo eu quero apresentar uma outra figura que é essa figura aqui que também tem alguns pontos extremamente importantes para que você possa implementar criatura limpa de forma correta então vamos lá eu quero inicialmente separar esse círculos né a ideia de você ter círculos concêntricos e a partir dessa seta você percebe que a dependência sempre

é de fora para dentro ou seja a parte amarelinha aqui das entidades não depende de absolutamente nada ah Léo entidades que eu vou já entrar o que significa entidades depende dos bancos de dados não depende da web não depende da minha interface gráfica não a seta de dependência é sempre de fora para dentro ou seja dentro é o seu código mais puro é o código que representa as regras da sua aplicação sem nenhum Framework sem nenhuma biblioteca e a partir do momento que você vai indo para a camada mais externa você vai sujando digamos assim

né na verdade essa sujeira de freio mortos e bibliotecas acesso a banco de dados SQL transações tudo isso diz respeito a essa camada azul que a camada mais externa e a ideia de sujar Exatamente isso já com tecnologia isso já com código de infraestrutura e quando você vai entrando nas camadas mais internas você não tem esses códigos presentes você tem apenas as suas regras de negócio sendo expressas através da linguagem de programação mas eu queria separar aqui o círculo Vermelho e o círculo amarelo que é digamos assim o coração da sua aplicação que são as

regras de negócio mais os casos de uso que representam os fluxos e você tem aqui a camada externa azul que é onde você tem next de S post-gressql maisql qualquer banco de dados que você vai usar qualquer Framework web que você vai usar tudo isso fica nessa camada azul e essa camada azul não vai impactar não vai ser misturada com o código que representa o negócio da sua aplicação dentro do livro a arquitetura limpa o que ele chama de entidades entidades são as regras de negócio de domínio aqui você pode ter uma função ser uma

entidade Você pode ter uma classe representando uma entidade Você pode ter sei lá um código que representa uma regra de negócio de domínio aqui você pode separar em entidades objetos de Eventos você pode ter serviços de domínio tudo aquilo que você vai representar as regras de negócio do domínio da sua aplicação Léo O que é domínio domínio é a área de atuação toda empresa tem uma área de atuação tem um negócio que ela atua tem um problema que ela resolve exatamente dentro do software quando você modela esse problema do mundo real em software você vai

definir processos você vai definir dados vai definir comportamentos ricos toda essa modelagem que você vai transformar isso muito provavelmente usando orientação objetos você vai colocar aqui dentro dessa parte de entidades ah Léo mas eu quero modelar usando programação funcional Então as suas entidades serão funções que vão trabalhar com os dados e transformar esses dados legal nós temos aqui os casos de uso os casos de uso não é o local que você vai colocar as regras de negócio de domínio você vai basicamente dentro dos casos de uso coordenar os fluxos a sua aplicação os casos de

uso eles funcionam como um grande integrador Como assim integrador Léo você vai integrar banco de dados você vai integrar é um serviço de mensageria você vai integrar vários serviços para coordenar um fluxo e esse fluxo vai te entregar uma funcionalidade uma característica da aplicação um cenário de uso da sua aplicação Ah vamos supor que você está Cadastrando um curso e dentro do curso você tem lá para mover um capítulo para antes do outro por exemplo isso poderia ser um caso de uso o caso de uso poderia ser persistir um curso alterar excluir um curso excluir

uma aula mover uma aula para cima para baixo você vai mapeando esse cenários de uso da sua aplicação e você cria os casos de usos sempre que os casos de uso né como um grande integrador precisar acessar algum tipo de serviço de infraestrutura ou seja ele precisar acessar aqui a camada de banco resultados que é a camada azul ou acessar alguma coisa relacionado a um serviço de mensageria alguma coisa que remete a infraestrutura não é possível que esse acesso aconteça de forma direta isso fica claro exatamente pelas setas ou seja não há uma seta do

caso de uso apontando para parte de infraestrutura ou para os frameworks que você vai usar na sua aplicação Então como é que eu faço para resolver essa questão da dependência já que o caso de uso ele é um grande integrador e ele é o maior cliente das suas entidades entidades aqui como termos genérico das implementações das suas regras de negócio que podem ser como eu falei né um objeto uma função Você pode ter lá uma classe que representa uma entidade um objeto de valor tudo isso faz parte dessa camada aqui amarelinha que é exatamente o

local que você vai colocar as regras de negócio então esquece aquele padrão de você usar objetos anêmicos só tem os atributos e os métodos gathers insetos e você vai colocar dentro desses objetos os comportamentos ricos ou seja as regras de negócio do seu domínio tá e o caso de uso é o maior cliente dessas regras de negócio então você não vai replicar as regras de negócio que estão nas entidades dentro dos casos de uso né o caso de uso é basicamente um integrador ele vai coordenar um fluxo de uso da sua aplicação mas para que

ele possa ter acesso a um banco de dados para que ele possa ter acesso algum tipo de interface externa o que a gente vai usar aqui é um padrão princípio de design chamado inversão de dependência que inclusive é um dos princípios do sólido a última letra lá letra D que é o Depp o princípio da inversão de dependência basicamente você vai criar interface dentro dessa área vermelha aqui você vai criar uma interface que representa um algo que você precisa acessar por exemplo Ah eu preciso acessar uma coleção de dados ou um repositório de dados você

cria uma interface colocando as funcionalidades que você precisa do ponto de vista do negócio não do ponto de vista de infraestrutura Ah você não tá preocupado se você vai acessar essa coleção de dados em memória essa coleção de dados vai ser um banco relacional ou um banco não relacional não importa você define do ponto de vista de negócio O que é que eu preciso para salvar os dados dentro de uma coleção de um repositório de dados Ah eu preciso essa função de salvar essa função de consultar aqui por esse atributo eu quero excluir eu quero

fazer essas operações com essa coleção de dados você define uma interface e usando o princípio da inversão de dependência que inclusive tem um vídeo no canal eu mostro para vocês lá arquitetura hexagonal trabalho muito bem essa ideia de portas adaptadores é um complemento talvez até um pré-requisito para esse vídeo dá uma olhada lá no vídeo de portas adaptadores que é muito interessante e usando esse princípio você consegue quebrar essa dependência que existe entre caso de uso e a camada azul que a camada que interagem com os frameworks e bibliotecas e a parte de infraestrutura você

investe a dependência e você passa essa dependência aqui para dentro do caso de uso de tal forma que ele vai conseguir usar o banco de dados sem conhecer Que tipo de banco de dados é sem entender como persistir os dados no banco de dados porque tudo isso estará sendo descrito aqui na camada azul é aqui que você vai usar SQL aqui que você vai usar peido Fire base aqui que você vai usar api do Next de S e qualquer outro Framework da sua aplicação lembrando os casos de uso e as entidades é eles serem puros

é para que você possa colocar aqui tendendo a zero a quantidade de bibliotecas e fraiburgos que você vai usar aqui dentro não quer dizer que você vai ser extremamente rígido e não usar nenhuma biblioteca dentro das suas entidades ou dentro dos casos de uso Às vezes você tem uma biblioteca que é mais simples que não vai gerar um impacto arquitetural muito grande e você usa ela dentro aqui dessa parte vermelha e amarela que seria o coração da sua aplicação mas você deve ter muito cuidado na hora de colocar é que dependências externas dentro das suas

entidades e casos de uso porque aqui é onde mora de fato o coração da aplicação beleza eu falei muito aqui da parte vermelha e amarela que é o coração da aplicação e da camada azul e para que que serve essa camada verde aqui a camada verde é exatamente uma camada de adaptação até coloquei aqui ó adaptadores de interface basicamente é o seguinte quando você vai pegar dados de um formulário lá na sua aplicação web você vai receber esses dados em um determinado formato ele vai chegar lá uns pouco e no formato de som lá tipo

um objeto com chave valor e você quer transformar esse objeto chave valor em uma entidade Ou seja que você vai utilizar aqui dentro do caso de uso como é que eu faço para transformar esses dados que vieram num formato diferente do formato que eu espero utilizar dentro das minhas regras de negócio é exatamente aqui nessa camada verde que você vai adaptar os dados que você recebeu na camada azul e você vai adaptar novamente os dados que você vai devolver do seu negócio para ser exibido na camada Azul você pode pensar essa camada azul de frameworks

e drivers como sendo uma camada de uma camada de entradas e saídas Como assim Léo entradas e saídas você vai ter lá sua aplicação e o usuário vai digitar várias informações na sua aplicação web ou seja informações de entrada essas informações de entrada precisam ir lá para sua camada de negócio para os seus casos de uso para suas entidades para que possa ser executado as regras e depois que essas regras foram executadas os processos forem digamos assim executados você vai devolver esses dados para serem exibidos por exemplo na sua camada azul né de frameworks e

drivers Então você vai ter o output também dessas informações Então como você tem essa ideia de entradas e saídas da camada azul que é a camada de frameworks drivers esses dados de entrada precisam ser convertidos para entrar na sua camada de negócio e você realmente tem uma separação é importante Esse aspecto né que você não pegue as suas entidades que essa camada amarelinha e use diretamente as entidades dentro da camada azul porque porque se você pega suas entidades na camada amarela não usa diretamente lá na camada dos frameworks você acaba criando um alto grau de

acoplamento entre as suas entidades e os frameworks o que vai acontecer é que uma hora ou outra você vai precisar mudar alguma coisa na camada azul que vai gerar um impacto direto na sua camada de entidades que é exatamente o coração na sua aplicação Então essa camada verde Ela também tem um propósito de proteger de separar aquilo que representa o negócio da sua aplicação e aquilo que representa as outras coisas né a parte externa que são frameworks bancos de dados interfaces gráficas dispositivos ou interfaces externas que você precisa interagir Outras aplicações que você precisa interagir

então a camada verde tem a ideia de fazer essa adaptação dos dados daquilo que você recebeu a partir do seu tremor que entrou na camada de negócio você transformou esses dados para que eles sejam executados dentro da camada de negócio que é os casos de uso e as entidades acontece a execução desses fluxos os dados são devolvidos e são transformados para mandar isso de novo para a camada azul na próxima aula eu vou entrar um pouco mais em detalhe falando para vocês Qual a ideia do presente e qual a ideia do controle vou falar um

pouquinho sobre essa ideia o que é uma porta de saída O que é uma porta de entrada como é que você consegue executar o fluxo chamando o caso de uso e aí eu já falei para vocês né que o caso de uso é o maior usuário né o maior cliente das suas entidades então se você implementar as regras de negócio dentro dessa camada amarela você não precisa implementar as regras de negócio na sua camada Azul ah Léo essa partezinha amarela e vermelha está no back end depende Depende da forma como você empacota isso ah eu

vou chamar os meus casos de uso através de uma payrash você já tem Rash não estará dentro do seu caso de uso a pirex chamar o caso de uso Ah eu quero chamar um caso de uso através de um botão da minha interface gráfica sem fazer uma chamada remota pode pode porque quando você define os casos de uso e você define as suas entidades aqui dentro não está dizendo que esse código é do back end aqui dentro ele não está dizendo que esse código vai depender de um aprash aqui dentro não está dizendo que esse

código vai ser chamado diretamente pela sua aplicação net GS aqui dentro só tem regras de negócio regras de negócio e regras de aplicação quando ele chama regras de negócio de aplicação tá dizendo que é basicamente os fluxos da sua aplicação e aqui na parte amarela de fato são as regras de negócio dos domínios ah preciso fazer um cálculo você faz aqui nessa camada amarela eu preciso implementar que uma regra também aplicação que os dados tem se comportar assim assim assado na camada amarela e a camada vermelha é uma camada de integração você vai integrar para

que os fluxos possa funcionar e aí você vai usar aquele princípio que Eu mencionei que é o princípio da inversão de dependência você passa para dentro dessa camada vermelha as implementações dos acessos a dados a implementação de qualquer tipo de dispositivo externo que precisa ser acessado através aqui dos casos de uso e a camada verdinha é exatamente essa camada para adaptar tanto os dados de entrada como os dados de saída que vão fluir digamos assim né entre essas camadas saindo da camada mais externa indo para sua camada de negócio e voltando para a camada mais

externa imagina a web é um grande Iron entrada e saída imagina o banco de dados é um grande ayo entradas e saídas todas essas entradas e saídas com o mundo exterior vai passar aqui pela camada verdinha para fazer esse processo de adaptação dos dados mas eu vou explicar um pouco mais a camada verde na próxima aula quando a gente for falar que desse fluxo entender um pouquinho essa questão porta de entrada e porta de saída para dar uma dica para vocês assiste o vídeo de portas e adaptadores porque essa porta aqui pode ser usada da

forma como a gente implementou também lá no vídeo de arquitetura hexagonal portas e adaptadores legal Espero que tenha ficado Claro alguns conceitos importantes claro que para ficar mais claro ainda tem que implementar tudo isso e por isso eu quero te convidar novamente para o nosso evento online gratuito ao vivo vai ser muito legal interagir com vocês lá a gente vai falar muito sobre arquitetura limpa nós vamos falar sobre casos de uso nós vamos falar sobre testes nós vamos falar sobre modelagem Rica vamos mostrar tudo isso na prática link na descrição se inscreve É uma grande

oportunidade para a gente interagir juntos e juntos desenvolver esse conhecimento na prática para que você possa entender como implementar aplicações fortes aplicações fracas são controladas por frameworks e aplicações fortes violão o código completamente inclusive controlam o acesso aos frameworks não são misturadas é muito comum você encontrar aplicações completamente misturadas afrombox E essas aplicações acabam sofrendo muito porque Frei mortos mudam o tempo todo e o teu negócio ele não pode ficar a mercê ou ficar Refém de Framework nenhum então essa separação é muito importante é uma separação que a gente vai falar muito nessa semana do

dia 2 a 4 de outubro então não perde se inscreve a gente se vê lá no evento e também se vê nos próximos vídeos aqui no canal da cover [Música]