Criando um projeto Spring Boot com Arquitetura Limpa

[@willianfn]

Essa sacada de pegar um projeto com uma estrutura já conhecida e transformar em clean foi genial!!! ajudou muuuuuuuuito a entender!!!

[@adspacheco]

4min. e já percebo que valeu mais doq as horas assistidas de cursos pagos. Só seu overview explicando início ao fim um projeto me ajudou mto e da pra ver o quanto vc tem o dom. Parabéns 👏🏻

[@giulianabezerra]

Vlw pelo apoio! Eu curto demais ensinar, me motiva, principalmente quando tenho feedbacks como o seu. Obrigada pelo incentivo e reconhecimento! 🤩🙏

[@carlosismael4800]

Giuliana, que sensacional o seu conteúdo! Parabéns! Essa ideia de pegar um projeto existente e funcional e refatorar para clean arch foi demais. Ajudou bastante no entendimento.

[@giulianabezerra]

Que bom que deu pra entender! 😊

[@igornobregadev]

didática sensacional!

[@iratuan]

Muito legal minha cara. Sua explicação é muito boa. Parabéns.

[@rdgtog]

Maravilhoso exemplo! Eu sempre ouço falar em Clean Architecture. Mas confesso que não sabia o que era. Já tinha procurado e lido a respeito mas não tinha entendido nada. Agora já sei o que é. Valeu Giuliana! Até o próximo vídeo!

[@giulianabezerra]

Que bom que curtiu! Quero trazer mais vídeos práticos a respeito de outras arquiteturas também (hexagonal, onion, ...)

[@edsonmartins1188]

Exemplo tão claro e didático quanto a apresentadora! Parabéns, nem todos conseguem ser tão claros como você foi.

[@wagnerroque7523]

Sensacional exemplo! Agora ficou mais claro esta arquitetura limpa! Obrigado!

[@giulianabezerra]

Que bom que ajudou, Wagner!

[@TheMaxwell880]

Já trabalho a alguns anos com o spring, e estou revendo diversos pontos que havia anotado na minha lista do que preciso melhorar, e sinceramente acho que esse conteúdo foi o melhor que vi até o momento. Muito obrigado por compartilhar esse conhecimento

[@giulianabezerra]

Obrigada pelo feedback e pelo apoio! 🙏

[@marcosgarcia179]

Excelente, gostei de sua ponderação...tudo depende do que estamos tratando e lhe dando.

[@juliotavares3268]

Ótimo conteúdo, simplificando muita valeu Guiliana!!

[@fernando-felicio]

Vc é braba mesmo Giuliana. Além de Dev também lê mentes. Kkkkkkkkkk Que conteúdo top. Não vejo a hora de terminar outras coisas pra poder iniciar os seus cursos na Udemy. Obrigado pelo material.

[@giulianabezerra]

Muito obrigada, Fernando! Espero que goste dos cursos 😁

[@silassouza7912]

Parabéns, foi bem explicado e de uma maneira muito simples.

[@leonardorosa5682]

Parabéns pelo conteúdo, muito didático!

[@marcossouza7435]

Excelente, sua explicação é muito clara e objetiva! Parabéns de verdade mesmo!

[@alvaroduartead]

Parabéns pelo vídeo, simples e eficiente

[@alexasasouza]

Uma baita aula, em pouco tempo, com um projeto sucinto. Parabéns.

[@tiagosindra3443]

esse é o melhor vídeo do youtube que irei assistir esse ano. muito foda! Giuliana muito braba, salvou minha vida!!!

[@luasluckas]

Muito obrigado pela aula! Finalmente uma explicação prática e clara sobre, sem precisar ver vídeos de horas kkk

[@barbagod9707]

Finalmente algo mais detalhado nossa, isso me ajudou demais agora a entender melhor!! muito obrigadooooo

[@giulianabezerra]

Que bom! Fico feliz que o vídeo tenha sido esclarecedor pra vc 🤩

[@DanielOliveira-xr6rq]

Excelente o exemplo e a explicação! Já tinha visto outros videos, mas nenhum foi tão esclarecedor como o seu. Parabéns! 😀

[@giulianabezerra]

Que bom que ajudou, essa era uma dúvida que eu tinha e me incomodava que grande parte dos conteúdos sobre o assunto fossem muito técnicos com pouca prática.

que conteúdo que vídeo que canal! parabéns!!

[@gregoriopteixeira]

Caramba! Adorei o vídeo. Muito bem explicado. E ainda tirou minha dúvida sobre utilizar essa arquitetura em projetos pequenos e microsserviços.

[@Gabriel_Cirilo]

Esse vídeo em poucos minutos esclareceu 100% sobre a estruturação de um projeto, minha mente agora compreendeu de forma extremamente simples. Meu grandessíssimo OBRIGADO!!🙌

[@giulianabezerra]

Eu sempre encontrava conteúdos super teóricos, resolvi trazer algo mais prático e sucinto, que bom que te ajudou, tbm me ajudou a organizar as ideias a respeito da clean arch 🤩

[@rodrigotenorio3424]

Excelente conteúdo!

[@luizgustavocantrella6166]

Já havi visto um projeto bem robusto com arquitetura limpa, porém fiquei foi é bem confuso rsrs Com essa sua abordagem e vendo a aplicação sair de algo que já estou familiarizado para a arquitetura limpa ajudou bastante na assimilação dos conceitos. Mandou bem de mais. Parabêns Giuliana!!!

[@giulianabezerra]

É isso mesmo! Quando eu tava lendo o livro e estudando o assunto procurei muito por projetos mas eles sempre eram muito robustos ou incorretos. Pensei em trazer um projeto realmente baseado na clean architecture que fosse didático pra quem está acostumado com o modelo camadas do Spring. Que bom que vc captou a ideia, fico muito feliz! 🤩

[@eovinicius10]

Didática impecável

[@IsraelSantiagoBH]

Gratidão Giuliana ! Extremamente claro e direto ao ponto, obrigado por compartilhar o seu conhecimento e a sua didática!

[@gabrieldragone]

Ótima didática!

[@gleniomontovani5350]

Ola Giuliana! Tenho um bom tempo como dev e foi a melhor explicação sobre clean architecture que já vi. Levei bastante tempo para entender essa arquitetura porque como você disse é muito verbosa. Parabéns pela explicação e quem quiser realmente aprender já tem um excelente caminho com esse video. Abraços.

[@giulianabezerra]

Fico feliz com teu Feedback, acredito que a teoria pode emergir da prática por isso uso esse formato de vídeo pra explicar conteúdos mais teóricos. Obrigada pelo apoio 🙏🤩

[@hudsonlucas5049]

Muito foda Giu! Tava caçando alguém que fizesse do zero, para me ajudar a entender a estrutura e os padrões

[@djahr]

Achei muito "da hora". Gostei demais de tuas explicações. Pessoal, são conteúdos desses que tazem considerações e demonstraçoes práticas e bem elencadas que precisamos para ganhar insights na nossa jornada! Agradeço a @Giuliana pelo conteúdo. Show!

[@giulianabezerra]

Que bom, agradeço demais a força! Tento sempre trazer conteúdos que tragam esse senso crítico e maturidade pra nós que trabalhamos com TI, e fico bem contente que vc tenha captado e curtido essa proposta 🤩

[@lucassouzati]

Primeiramente, obrigado por mais um vídeo excelente Giuliana! Coincidentemente eu estava estudando Clean Architecture agora mesmo, e já buscava exemplos de implementação com Java e Spring. Particularmente o que mais gostei dessa abordagem, é te forçar a pensar no seu sistema de forma que ele pudesse "rodar numa folha de papel", ou seja, independente de fatores externos. Eu acho que a principal vantagem é a testabilidade do código, que fica muito mais fácil. Por outro lado, seus apontamentos são bastante válidos e seguir a Clean Architecture a risca vai gerar um código muito verboso. Por isso, prefiro mais a ideia de se aproveitar dos conceitos, e trazer pra algo que seja mais convencional. Aliás, eu estava lendo o livro Uncle Bob "Clean Architecture", e a arquitetura foi toda baseada nos princípios SOLID. Falando nisso, acho que SOLID aplicado daria uma série maneira no seu canal hein kk Valeu #tdcremoto

[@giulianabezerra]

A ideia é interessante, mas adiciona muitas camadas de abstração que pra sistemas pequenos não faz muito sentido. Testabilidade é uma grande vantagem que acabei não mencionando no vídeo, mas fica claro pq o isolamento das camadas permite mocks nas integrações, boa observação! O tema solid tá na minha lista tbm, junto com design patterns, obg pelo feedback e sugestão! 🤝

[@ricardofarias1443]

​@@giulianabezerramuito bacana aplicar os princípios do solid e padrões de projeto. Um projetinho mais completo seria muito bom.

[@giulianabezerra]

@@ricardofarias1443, boa! Tá na lista aqui uma série sobre solid e design patterns 😉

[@VelkanRF]

Muito boa a iniciativa. Eu uso esse padrão do Tio Bob a um tempo e realmente nao gosto dele. É bom, ele protege as camadas internas mas a um custo muito alto. Na minha humilde opinião, ainda precisamos melhorar esse novo padrão para diminuir a complexidade do projeto. A ideia de proteger a camada de negócio é antiga, e temos muitos patterns que nos ajudam, regras de encapsulamento, SOLID, modelos de Design. Nesse seu exemplo ainda é uma versão simplificada, veja a verão gerada pelo pessoal da Full Cicle. Imagine de o su usuário precise ganhar 2 novos campos. Vc precisa alterar quantas classes? 5..6. É péssimo. Toda a literatura do Bob, tudo gira em torno de produtividade. Foi gerado esse modelo pra desenvolvedores conseguirem dar manutenção em grandes projetos de maneira eficiente. Produtiva. Queremos proteger as regras de negócio, pra nao ter tanta dor de cabeça na hora que precisamos mudar algo. Então a pergunta chave é, quando essa complexidade se paga? Acho q o Bob precisa lanças uma versao prática desse modelo que sem dúvida é interessante. Adorei seu vídeo. Parabens.

[@giulianabezerra]

Exatamente. Dizer que uma arquitetura é “a melhor” não faz sentido, pq tudo em ti é tradeoff. A questão é avaliar se pro contexto vale a pena pagar o preço.

[@joaovitorsantana8581]

Sempre tive dificuldade em entender esta ideia de isolar a aplicação da regra de negócio. Gostei muito do conteúdo!

[@ClevertonNeves-x7k]

O seu conteúdo é maravilhoso. Extremamente claro e direto ao ponto. Obrigado por compartilhar o seu conhecimento e a sua didática.

[@giulianabezerra]

Que bom que o conteúdo agradou e agregou valor, esse é meu objetivo :)

[@huds8n]

Faltou separar em módulos para evitar que uma camada interna conheça uma camada externa. Eu tmb sou da galera que torceu o nariz pela falta da interface ali. Mas não tem o que pontuar negativamente, o video foi excelente.

[@thiagousetelni7343]

Excelente!

[@allanneri6096]

Ótimo conteúdo. Aprendi bastante. Inclusive, não conhecia o tipo record. Vou pesquisar sobre ele. 🙏🏻👏🏻

[@giulianabezerra]

Obrigada! Tenho usado muito os records, recomendo!

[@DenisioRodrigues]

Muito bom!

[@eduardoaraujo9988]

Parabéns Giuliana, seu canal é uma benção pra quem ta começando agora, continue com o conteúdo, parabéns!

[@giulianabezerra]

Muito obrigada 🙌

[@jrdevcj]

Explicação, massa! Vlw, conteúdo!

[@giulianabezerra]

👏🏻😉

[@BenjamimDenis]

Parabéns, prático direto ao ponto, diferente de umas instituições aí q inflamam o conteúdo com história e o prático zero.

[@giulianabezerra]

Obrigada, que bom que curtiu! 😊

[@BenjamimDenis]

@@giulianabezerra so senti falta de um exemplo com o alterar, pois diferente do criar, no caso do alterar nao temos um identificador unico no negocio como um rowid, que define no banco de dados, e ai quando precisamos alterar um dado onde o seu itentificador unico poder mudar, teria de ter uma copia do objeto anterior com esse identificador unico + o novo objeto de dominio que vai sofrer o update

[@achilesluciano728]

Oi Giuliana! Ótimo conteúdo! Gostei muito do seu comentário final sobre quando a gente deve aplicar a arquitetura. Geralmente a gente sofre muito para entender esses conceitos e vira uma "moda" que o pessoal mais recente na área fica louco pra colocar em todo lugar. Vi vários projetos de microsserviços utilizando esta arquitetura e também a hexagonal e muitas vezes acaba deixando o projeto muito verboso e de difícil manutenção. Obrigado pela aula!

[@giulianabezerra]

É isso aí, senso crítico sempre.

[@eduardoorlandimelle9229]

Aula excelente! Muito obrigado!

[@j2alex01]

Muito bom seu vídeo, parabéns! Só um detalhe: no minuto 9:05 você referencia na camada de usecase a camada de application, isso viola as regras da camada mais interna desconhecer as camadas mais externas 😉

[@carinhadojava]

maravilhosa como sempre nas explicacoes

[@giulianabezerra]

Muitíssimo obrigada 🤗

[@davidpriston]

Olha, para quem está pegando de primeira, realmente não é muito simples de usar por ser bem verboso mesmo o código, mas é sensacional a ideia de uma arquitetura limpa, as suas aulas são ricas em detalhes e conhecimento e o vídeo pode-se dizer que é curto para o tanto de informação. Parabéns pelo conteúdo e espero de coração que continue compartilhando ainda mais conhecimento.

[@giulianabezerra]

Obrigada demais pelo apoio! É difícil simplificar um assunto que é coberto num livro inteiro, por isso resolvi trazer algo mais prático pra quem se embola (como eu) em teoria excessiva.

[@JeffersonLuizCruz]

Deu show. Que aulão.

[@giulianabezerra]

🤩🙏

Muito bom o conteúdo!!

[@giulianabezerra]

Gratidão, Claudemir!

[@DevHugoLeonel]

Seu vídeo me fez repensar sobre o TCC que estou fazendo, Clean Architecture é realmente complexo, mas desta vez eu entendi um pouco agora rs Achava que serviria para micro serviços.

[@giulianabezerra]

Viu aí? Quando vemos a teoria achamos as mil maravilhas, e aí ao trazer pra prática é que a gente identifica a aplicabilidade de fato. Microsserviços já tem um contexto menor e mais protegido do domínio, por isso acaba ficando redundante usar clean arch mesmo.

[@mart.]

Que aula

[@gabrielrochasantana]

Muito bom video Giuliana. Sigo você tem tempo aqui já, parabéns. Reparei na descrição do video embaixo quando coloca o mouse no tempo 13:01 : criando o "ilzerente" 🤣🤣 . Tava pensando aqui, que diabo é isso? Depois vi que era o UserEntity. Curiosidade, o youtube faz essa separação automática das trilhas?

[@giulianabezerra]

Kkk, sim ele faz automaticamente, por isso saem algumas pérolas

[@diogoboaventura4789]

Olá, parabéns pelo video, não consigo encontrar material orientando em relação a entidades bi-direcionais, você tem algum material sobre?

[@mayconrsantana6226]

Show de bola!!! Poderia por gentileza, fazer um vídeo implementando Multi-tenancy com Hibernate e Spring Boot?

[@giulianabezerra]

Sugestão anotada! Farei em breve 😉

[@mayconrsantana6226]

Obrigado@@giulianabezerra ficarei no aguardo ☺

[@ericksontulio5798]

Foi uma boa aula, parabéns! Entretanto, fiquei em dúvida sobre qual é de fato a utilidade dessa arquitetura. No inicio, estava estruturado o protejo com uma arquitetura de camadas onde quando foi modificado para o clean pareceu que ficou mais sujo do que limpo, pois, havia muita repetição de código onde o dto era igual a entidade e a entidade era igual ao modelo representativo jpa. Talvez, com um exemplo simples ainda não deu para notar a diferença além da estrutura.

[@luccasdev]

No exemplo demonstrado na video aula de fato o Clean Arch parece uma bazuca para matar uma formiga, onde o modelo convencial MVC resolve bem por conta da simplicidade. Porém imagine em um sistema corporativo, com diversas complexidades de negócios, ter as regras de negócio ao máximo desacoplado e independente garante delimitação de responsabilidade entre as camadas e maior flexibilidade para mudança de componentes como sistema de mensageria, banco de dados, framework, etc... O que eu quero dizer é o Clean Arch bem executado em um sistema complexo traz diversos benefícios, e talvez na video aula possa parecer que não fique claro pois o exemplo demonstrado é um CRUD simples.

[@ricardoantoniosouzaa]

Muito bom!!! Bastante semelhante ao Hexagonal mudando somente os nomes e a localização dos artefatos rs...

[@ricardoantoniosouzaa]

Fica até a sugestão de Hexagonal Arch ai.... rs

[@giulianabezerra]

Bem observado! Pouca gente nota isso, mas o fato é que não existe nada de revolucionário na clean arch, ela é apenas uma “releitura” da ports and adapters, hexagonal e onion.

[@ricardoantoniosouzaa]

@@giulianabezerra Confesso que acho o Hexagonal mais organizado e fácil de entender rsrs... mas vc colocou muito bem agrega, uma grande complexidade que não vale a pena em certos projetos

[@eduardonunes1379]

Muito bom! Tenho uma dúvida, se por exemplo o user tivesse um relacionamento com outra entidade, telefone por exemplo. Usando a arquitetura em camadas, a forma que eu geralmente faço é um service se comunicando com outro (não um service se comunicando com um respository de outro modelo)... Nessa clean architecture, eu imagino que UserRepositoryGateway possa se comunicar com outro gateway para realizar isso, é assim? por exemplo um PhoneRepositoryGateway...

[@welksonnn]

Top

[@alabvix]

Só um detalhe: o seu UseCaseInteractor está diretamente acoplado ao framework, nesse caso você viola o princípio de Inversão de Depência (DIP), uma das bases da Clean Arch. Nesse caso, você pode usar uma interface para o use case do mesmo jeito feito para os gateways. Isso faz toda a diferença na hora de modularizar a camada de negócio, caso queira criar uma biblioteca, por exemplo.

[@MrMatheus195]

??? Aonde que tá acoplado ???

[@alabvix]

@@MrMatheus195 o use case é chamado diretamente. Ele é uma classe considerada de alto nível, nesse caso, a recomendação é usar DIP. Um dos objetivos da Clean Arch é permitir toral modularização, desse jeito, o módulo do framework vai depender direto de uma classe concreta, quando, na verdade, deveria usar uma interface, pois assim, os módulos podem ser compilados de forma independente. Isso tá no livro do Uncle Bob, ele frisa muito essa questão.

[@MrMatheus195]

@@alabvix Ah sim sim, mas isso é totalmente desnecessário cara. Um caso de uso é...um caso de uso! Se existe a necessidade de realizar outra implementação de um caso de uso, eu penso que é na verdade outro caso de uso.

[@alabvix]

@@MrMatheus195⁣, mas esse não é o caso. A interface é só uma 'porta' para o caso de uso que garante 100% desacoplamento. A ideia de interface não é você permitir somente várias implementações, é você tornar o sistema mais robusto e fácil de expandir, que são objetivos da clean arch. Daí recomendo você dar uma olhada no DIP mais a fundo. É claro que se o sistema não vai ser modularizado, não vai crescer, aí talvez nem vale a pena usar Clean Arch.

[@FabioEbner]

Boa noite, adorei o video. Sera que voce conseguiria fazer um no mesmo estilo porem para um projeto um pouco mais complexo? por exemplo como a Arquitetura limpa trabalha o relacionamento entre entidades? imaginando um mundo de um pedido -> itens (1 pedido possui N itens) segundo a arquitetura limpa eu teria na entidade Pedido uma lista de Itens ou faria esse relacionamento apenas na tabela item (pelo pedido_Id) e com o a arquitetura limpa trabalha a forma de recuperar esses dados. .por exemplo tenho 1 servico que ele busca os dados do pedido e os itens e junta tudo em um retorno para o meu cliente, ou sao 2 servicos separados e o cliente precisa chamar eles separadamente ? obrigado

[@julianocavalcante7683]

Nesse caso acho que o problema não é tanto arquitetura limpa. Arquitetura limpa diz mais respeito a como você isola o seu código em camadas de forma a proteger a regra de negócio e regras de aplicação. Você poderia realizar essa implementação da forma que bem entendesse, contanto que não ferisse as regras de dependência da sua arquitetura estaria tudo certo. Agora o que eu te recomendo é buscar por Domain Driven Design (DDD), busque por: Design Estratégico, Design Tático, Bounded Contexts, Aggregates, Entities e Value Objects. Todos esses são conceitos que vem do DDD. Todos os conceitos acima podem ajudar vc se a profundar a tudo que diz respeito ao que está na camada de domínio de uma aplicação usando Clean Architecture. Mas na prática, o importante é entender que: Entidade em DDD, ou mesmo em qualquer outra forma de conceber a parte de domínio, é diferente de Entidade ou Model do ORM (caso vc use ORM) portanto vc sempre vai ter que tomar decisões em como vc vai representar uma "entidade composta" no seu domínio vs no banco, até porque seu banco pode ser relacional ou não relacional, o que muda como vai ficar sua implementação a nível de infraestrutura. No geral, eu modelaria um PedidoRepository, que carregaria tudo. A grosso modo, Repository é um padrão que vem do DDD também, e a função dele é carregar dados de alguma fonte de dados. Como Pedido poderia ser um agregado (aggregate do DDD), uma forma especial de composição de entidades, vc teria um repositório pra lidar com ele inteiro. Em tese o agregado é uma "unidade" inseparável, ou seja, sempre que vc quiser mexer em um item, vc tem que mexer via o agregado, que é o pedido, então perde-se o sentido de carregar o item sozinho, já que o item só existe dentro de um pedido. Mas aí o tópico vai longe e tbm posso falar besteirinha, faz pouco tempo que comecei a mexer mais ativamente com DDD e Clean Arch, mas talvez pesquisando por esses assuntos ajude vc a ter novas visões de como modelar esse problema.

[@uluizeduardo]

Primeiramente, gostaria de parabenizar pelo excelente conteúdo e pela didática impecável! Sua explicação torna até os conceitos mais complexos acessíveis. Tenho uma dúvida que pode parecer simples, mas gostaria de ouvir sua perspectiva. Ao considerar o caso de uso (interactor) FindUserInteractor, percebi que na classe de domínio/entity não há um identificador (id) no registro do User. Como você aborda a busca desse usuário por meio de um id nesse contexto específico já que a regra de negócio fica no caso de uso? Agradeço pela atenção e continuo acompanhando seus vídeos com grande interesse!

[@giulianabezerra]

Excelente pergunta! Se o id é importante para a regra de negócio ele pode ser usado na classe de domínio, pq ele é necessário para diferenciar entidades. Eu não usei no exemplo pq não tratei essa funcionalidade, mas se fosse necessária uma busca por identificador eu poderia sim adicioná-lo ao domínio pq a regra de negócio é buscar unicamente uma entidade, e a regra de unicidade utiliza o conceito de id, identificador único. Lembre-se de que o id não existe apenas no banco de dados, a gente usa ids também em regras de negócio, por exemplo, o cpf de uma pessoa é uma espécie de id. Espero que tenha ficado claro e obrigada por acompanhar os conteúdos :)

[@grafpres2734]

show, mas essa parte do sql, se for varias tabelas só colocar todos sql de criacao na mesma pasta que ele vai reconhecer?

[@arozendojr]

Sugestão, poderia fazer um exemplo usando Gateway, sabe como fosse um orquestrador, chamando alguns endpoint , gostaria de saber como você modela. Interface dos Gateway nos pacotes, sabe onde você coloca os model das request e response de cada implantação , em fim desejo sucesso

[@giulianabezerra]

Se for com Gateway provavelmente seria com microsserviço e nesse caso eu não usaria cleanarch pq o ônus superaria o bônus. Mas se for um monólito, eu teria algo como mostrei no vídeo, sem centralizador de requisições.

[@arozendojr]

@@giulianabezerra 🤔 Pessoal falam que arquitetura limpa e DDD são muito bons para estrutura de BFF + OQR , você acha que um ORQ em MVC sairia melhor ?

[@fknoliveira]

Uma dúvida: não seria interessante criar uma interface para o UserController? Estou pensando em uma cenário que seja necessário expor os use cases de outra forma além do REST, por exemplo via Socket/EJB. Conteúdo muito bom, obrigado por compartilhar.

[@giulianabezerra]

É possível, mas como arquiteta posso dizer que é bem improvável que depois de definir uma arquitetura para o sistema web, seja feita uma mudança drástica (a não ser que tenha sido bem mal arquitetado). Normalmente pra mudar de um rest pra socket (mudança grande) seria necessário uma nova análise de arquitetura então não seria apenas substituir a implementação de uma interface. E aí o ganho de usar uma abstração acaba sendo bem ínfimo.

[@cassioribeiropereira8334]

Quando cheguei nesse vídeo, estava com muita raiva do tal Clean Architeture, agora continuo com raiva, mas bem menos. Acho que consegui entender mais vantagens e conceitos, muito obrigado.

[@giulianabezerra]

Kkkk, eu também tenho raiva, tmj!

[@hamiltonmbrito]

Giuliana, excelente material didático, a ideia de um projeto simples é perfeita para entendermos os conceitos, entendo também que para um projeto pequeno essa abordagem pode ser muito verbosa, mas, por outro lado, se tivéssemos 37 entidades ao invés de apenas uma, a manutenção do código se tornaria bem mais trabalhosa, não é?

[@giulianabezerra]

É tradeoff mesmo. Se o custo e benefício de manter a regra de negócio isolada justifica o de gerenciar milhões de abstrações, aí vale a pena ir nesse caminho.

[@denneralmeida]

Gostei bastante do exemplo. Parabéns Giuliana . Gosto muito da Clean arch e a Hexagonal, mas em alguns projetos pequenos fica realmente com o over engineering :( . Também dá pra diminuir o boilerplate da configuração dos beans utilizando o Javax Inject já que ele segue a JSR-330 que é uma especificação do Java, tanto Spring, Micronaut e Quarkus, respeitam essas especificações. Assim não precisaria dessa camada a mais.

[@giulianabezerra]

Muito bom teu comentário, a sugestão é super pertinente, já cortaria algumas classes!

[@JFelipe71]

Giuliana, primeiramente, muito obrigado pelo conteúdo incrível, sua didática é ótima. Eu venho do PHP com uma certa bagagem em aplicações feitas com Clean Architecture. comecei meus estudos em java e estava indo tudo bem. mas estou tendo dificuldades para iniciar um projeto de API com spring + clean arch. seu vídeo me ajudou a entender melhor como posso desacoplar as camadas, mas tenho uma dúvida: com a organização de você sugeriu aqui, eu fico preso na necessidade de criar um gateway pra cada entidade? repetindo um grande volume de códigos idênticos, como as operações básicas de CRUD? tenho tentado há dias criar uma abordagem que me permita desacoplar as camadas e reaproveitar código, ao mesmo tempo. mas com o spring, não consigo de jeito nenhum. ou eu acabo escrevendo muito código duplicado ou sujo minha aplicação com recurso do framework

[@wevertontsousa]

Usar "Generics" não ajudaria?

[@didamendes]

Otimo conteudo. Não sabia que tinha um canal. Posso considerar esse conteudo como um arquitetura hexagonal ?? Ou para ser uma arquitetura hegaxonal deveria mudar alguma coisa ??

[@giulianabezerra]

Clean arch é baseado (ou copiado) da Hexagonal, vc pode considerar como uma especialização dela e da Onion tbm. É uma releitura dessas arquiteturas que vieram antes.

[@CAIORIOSSOUSA]

Oi, parabéns pelo vídeo. Uma dúvida, eu uso helper/facade em uma aplicação de arquitetura MVC para colocar as regras de negócio, orquestração de chamadas de apis e etc... nesse caso essa lógica ficaria no infrastructure/gateways certo ?

[@giulianabezerra]

Se o seu facade for apenas o orquestrador, ele seria o interactor do clean arch, que usaria as abstrações dos gateways e nas camadas externas vc colocaria as implementações dos gateways. Você teria que refatorar para mover os detalhes pras camadas mais externas.

[@VictorTavares27]

Excelente conteúdo e didática, Giuliana vc acha que seria possível fazer um vídeo explicando como usar a mesma autenticação em dois microsseguros diferentes com spring?

[@giulianabezerra]

Opa, dá uma olhada na playlist de segurança que tem no canal, deve ter dar algumas ideias pra usar nos microsserviços.

[@painnagato7617]

não sei se eu entendi, voce cria um dominio para que as regras de negocio sejam encapsuladas nele, criando classes ricas, ai voce vai lá e cria um record como entidade de dominio ? isso não transformaria sua entidade de dominio em um modelo anemico ? ja que os records são para transporte de dados

[@wevertontsousa]

Eu sou fã dessa didática. O que me deixa muito confuso, é a camada Adaptadores de Interface, nela dizem que também não deve ter frameworka, porém é nela que é descrita o diretório controller e a Implementação do Gateway.

[@giulianabezerra]

É que existe uma confusão entre clean e hexagonal, embora clean seja a cópia da anterior, o nome dos pacotes mudou e infraestrutura representaria a parte dos frameworks. Então acaba sendo como haver algumas diferenças na organização de pacotes, mas o importante nessa arquitetura é deixar clara a camada dos frameworks e não deixar essa configuração vazar pras outras.

[@wevertontsousa]

@@giulianabezerra obrigado por ter me respondido.

[@JoãoPedro-w2n4w]

Giuliana, uma pergunta: em uma aplicação um pouco mais complexa, com mais entidades que devem interagir com bancos de dados, devo criar um package separado para cada uma? por exemplo, dentro do package gateways, eu criaria um package apenas para categorias e outro para produtos, por exemplo? Mesma coisa para os usecases e as entities

[@wevertontsousa]

Excelente pergunta, eu também tenho essa dúvida.

[@petroniobonavides3530]

Giuliana, eu gostaria de sugerir, você nos mostrar "multitenancy" standard, com spring data e hibernate

[@giulianabezerra]

Opa, anotado! 😉

[@erickglock]

Mto Legal, entendi o propósito mas torna mais complexo o desenvolvimento msm, atualmente para microserviços o que se usa atualmente? mvc msm? abçs

[@giulianabezerra]

Eu gosto do package by feature, fica mais logicamente organizado

[@georgequeiroz6660]

qual esse utils q vc usa pra fzr o http, normalmente uso o curl

[@joaovitorsantana8581]

Giuliana, fiquei com uma dúvida. Confesso que fiquei acomodado com a utilização da annotation @Transactional nos services. Com a clean arch, só conseguimos utilizar este recurso nos controllers, certo? Pois aplicar este recurso nos interactors vai ferir o princípio da arquitetura. Neste contexto, tem alguma outra forma de contornar esta questão?

[@giulianabezerra]

Eu já vi alguns artigos falando que pode usar o Transacional do Jakarta, que aí é desacoplado de framework. Isso também vale pra anotações nas entidades. De fato faz sentido usar a spec, que é mais genérica, assim você se protege do acoplamento de um framework mais específico como o Spring.

[@andersonfuhrsouza7505]

Gostei da parte dos puristas hauhauha. Mas realmente optar por usar uma arquitetura nem sempre é a coisa certo assim como usar interface pra tudo, eu to tendando mudar esse pensamento e deixar as coisas sempre o mais simples possível.

[@giulianabezerra]

Que bom ouvir isso. Eu já passei por várias fases como programadora. A fase de querer usar padrão de projeto pra tudo, framework, fazer códigos mais reusáveis antes do uso em si. Hoje considero que a simplicidade é a característica que traz mais benefícios pro meu código e arquitetura e tento prezá-la sempre que possível!

[@xamgodoix]

Uma dúvida que tenho é como fica o controle de transações no caso do clean arch. Se fosse necessário, onde seria colocada uma annotation como @Transacition?

[@giulianabezerra]

O que eu vejo é normalmente o pessoal usando a @Transactional do Jakarta, como o Spring é compatível não teria problema em usar essa anotação no domain, por ela ser do Java mesmo

[@arozendojr]

interessante, conheci seu canal hoje, vou explorar seu conteúdo, gostei que você usa o VScode

[@giulianabezerra]

Que bom! Eu uso tbm o IntelliJ pra coisas mais complexas, mas vscode quebra o galho pra esses tutoriais 😁

[@wendelsoares2930]

Uma dúvida, eu sempre preciso utilizar esse modelo de arquitetura limpa? até nos meus projetos pessoais para treino por exemplo?

[@giulianabezerra]

Não, não recomendo usar a não ser que seu projeto pessoal seja para estudar essa arquitetura ou tenha aquela necessidade forte de proteger as regras de negócio.

[@douglas2085]

Como iniciante e já tendo feito algumas APIs simples e vendo outro tanto no KZbin e repositórios github por aí, tive alguma ideia do que vc quis passar. No entanto, não entendi qual o real problema de depender do framework.

[@giulianabezerra]

Parabéns, vc não é tão jr assim. Eu não acho que depender de framework ou banco seja grave pq é raro vc precisar trocá-los. Em mais de 10 anos de profissão nunca vi isso acontecer. Agora, se a regra de negócio ficar espalhada em diferentes camadas, aí de fato pode complicar a manutenção, então a arquitetura traz um ganho nesse ponto. Você sabe exatamente o que mudar, onde mudar, e pode mudar sem medo. E a outra facilidade é pra testes, pq ao isolar os "detalhes" (banco, web), vc consegue mocká-los facilmente sem precisar configurar mocks elaborados.

[@carlosnakagawa5983]

Uma dúvida..... duplicando o UserEntity no persistence, você não está indo contra o conceito de DRY ? Não existe outra forma de evitar isso ?

[@giulianabezerra]

Conceitualmente não pq a entidade representa o modelo de banco e o objeto de negócio é desassociado dele, eles devem evoluir independentemente pois existem por motivos diferentes. Mas se eles forem iguais estruturalmente, você pode usar a mesma classe com as anotações do Jakarta, e aí daria pra usar a mesma entidade pro negócio e pro banco sem contaminar a camada de negócio com anotações de framework.

[@eudumal]

eu adorei o vídeo. excelente didática e ótima explicação, mas cheguei a conclusão de que sou meio burro, achei um bem complicado entender o funcionamento, muitos arquivos, um chamando o outro que chama o outro... KKKKKK estou acostumado com a estrutura mais padrão de MVC, mas infelizmente preciso aprender novas maneiras e sair da zona de conforto. (sou junior)

[@giulianabezerra]

É difícil de entender mesmo, esse é o ônus dessa arquitetura, pra abrir mão da simplicidade os ganhos devem valer a pena. De fato é importante conhecer várias arquiteturas, mas focando em entender as vantagens e desvantagens tbm de cada uma.

[@eudumal]

@@giulianabezerra você tem algum outro vídeo mostrando outro tipo de estrutura? Gostei bastante da sua didática, obrigado por compartilhar seu conhecimento!

[@giulianabezerra]

Eu ainda vou trazer outras arquiteturas, tá na minha lista 👍

[@eudumal]

agora depois de alguns meses de estudo consigo entender melhor o que foi feito, e fiquei com uma duvida a classe UserRepositoryGateway não deveria chamar UserServiceGateway visto que ela estaria fazer um papel de service? faz sentido esse meu raciocinio? além disso, dentro da pasta infrastruture poderia ter a utilização do spring, certo? ao inves de criar a pasta main, não seria mais simples usar as notações do spring pra injetar? pergunto isso porque tive um pouco de dificuldade pra entender o seguinte trecho ``` @Bean UserGataway userGataway(UserRepository userRepository, UserEntityMapper userEntityMapper) { return new UserRepositoryGataway(userRepository, userEntityMapper); } ``` Desculpa o monte de perguntas kkkkkkk

[@vtj2890]

existe um video fazendo o projeto que foi refatorado?

[@giulianabezerra]

Esse projeto em particular não, mas tem vários tutoriais que explorar o desenvolvimento de projetos do zero

[@grupodeestudo2182]

qual é o seu teclado? gostei do som❤

[@giulianabezerra]

É um Keychron k3

[@nunolaranjeira3509]

Muito boa explicação mas esta arquitectura é "pesada".. tinha de ver isto implementado (e mantido) num projecto grande para perceber realmente os benefícios, mas deu para perceber finalmente a ideia e a lógica por trás da arquitectura limpa, algo que até hoje sempre que começa a ouvir ou ler.. era tudo mutio teórico e pouco prático. Num dia de loucura vou tentar refactorizar um projecto para esta arquitectura :) Mais uma vez parabéns e obrigado pelo vídeo.

[@giulianabezerra]

Concordo, é pesada mesmo. Por isso que vale sempre avaliar o tradeoff pra decidir usar ou não.

[@cesarsales22]

Em resumo: Clean architecture é top, mas o nome é uma droga kkk pq ao chamar isso de clean, deixa subentendido que os outros não são clean, ou seja, são sujos ahaha. Obrigado pelo vídeo!

[@giulianabezerra]

O uncle bob é um grande marketeiro, eles escolheu o nome pensando nisso. Tanto do code como da arquitetura. Como dizem, os grandes criam os gênios copiam, dando nomes mais bacanas pras coisas.

[@douglas7463]

#tdcremoto

[@benjaminfrank9166]

Can you please make it in English

[@giulianabezerra]

I'll add subtitles 😉

[@didamendes]

Ja vi gente que usou arquitetura hexagonal. So para dar um Hello Word. KKKK

[@giulianabezerra]

Eu fico espantada com isso, o pessoal vai criar um crud simples e já manda um clean arch, blz se for pra aprender ou fazer demo como fiz, mas em produção tem que ser avaliado o ônus e bônus kkk

[@codingwithraphael]

ta errado! o que voce fez foi só separar o projeto em diretorios fugindo do MVC. clean arch é muito mais que isso, é isolar dependencias externas de camadas mais próximas das regras de negócio para desacoplar os métodos e assim poder simplificar os testes doubles (stubs, mocks etc). a estrutura de pastas nao esta errado. mas o conceito esta!

[@codingwithraphael]

assim dito, compartilhar o pom faz com que voce acople todas as dependencias, qualquer seja a estrutura de diretorios que voce usar, MVC, camadas etc. há varias formas que fazer clean code e o multi module project é o mais comum. lembrando que o clean code na estrutura de micro serviços tambem gera muito mais complexidade, visto que na sua maioria das vezes sao baseados em eventos e ai precisa usar cqrs event sourcing, data consistency etc database per service e por ai vai

[@mosiahrs]

Muito bom!

[@giulianabezerra]

Vlw! 🤩