Temos um treinamento cujo objetivo é fazer com que você escreva código de qualidade independente da situação. Entendemos que aplicar as boas práticas com fluidez é o caminho mais interessante para que você consiga acelerar suas entregas gerando cada vez mais valor. Acesse em deveficiente.com
Eu adoro quando você fala "você vai ter que mexer e tá tudo bem...". Uma lição massa que aprendi com meu atual diretor foi "A gente de engenharia fica pensando demais em como fazer perfeito sendo que a solução que a gente entrega é software, é maleável, se der errado, refatora..."
Valeu demais pelo comentário! Eu realmente acredito o princípio do Open Closed de vez em quando coloca um peso extra... Modificar não precisa ser um problema.
Muito bom Alberto, mais do que seguir uma padrão ou o que quer que seja o código tem que fazer sentido. Na minha opinião a ideia de uma arquitectura limpa ou hexagonal se preferir, facilita muito na reconstrução da idea por um Dev que não é o mesmo que escreveu o código. Resumindo o código tem que ficar claro e facil para qual quer Dev. Acho que esse é o ponto. como garantir isso ? Depende kkk. muito bom o video
Opa, Alberto! Ótimos pontos. Concordo que devemos ter um olhar crítico sobre a quantidade excessiva de camadas, que muitas vezes são desnecessárias e acabam trazendo mais complexidade e custo de manutenção. Um ponto que considero é que, geralmente, temos times de engenharia com diferentes senioridades , e tomar "decisões coesas" para componentes de software ou se adicionamos ou não uma camada, exige experiência e um bom entendimento do domínio, competências que desenvolvedores menos experientes ainda estão construindo. Ao definir uma estrutura com N camadas e explicar que vamos utilizar um 'padrão' de mercado, talvez seja mais fácil orientar e estudar o que é cada uma. E, embora isso não nos garanta ter software melhores, sei que ao olhar para uma camada de serviço, encontrarei regras de negócio, quando olhar para um controller sei que vou ter: solicitações http, entrada de dados, alguma chamada para validar essa entrada... etc . Quando não temos isso bem definido, exige uma comunicação e documentação muito bem estruturadas no time; algo que geralmente não está disponível no início do projeto e pode levar tempo para ser desenvolvido. Como você vê esse ponto?
Opa Cleyton, eu adoro guidelines :). Considero que são fundamentais para fazer isso que você citou mesmo, trazer algum padrão para o desenvolvimento. Neste caso minha sugestão seria mudar o guideline :). É como você falou, pensando em código, deslocar praticamente 100% do código de uma camada para outra não facilita nada... E meio que é isso acontece dada a maturidade das tecnologias de apoio hoje em dia.
Sobre os casos de uso vs reutilização, por volta do minuto 6:40, o que a literatura fala sobre reutilização não é do ponto de vista de um caso de uso chamando o outro (isso não deveria acontecer), é do ponto de vista dos estímulos externos que executam o caso de uso. Esse é o reaproveitamento. É bastante comum ter um caso de uso que é executado por um estímulo de mensageria e também expor o mesmo via endpoint http para utilizar via scripts, por exemplo, ou que recebe via GRPC e tb REST, ou até mesmo dois endpoints rest mas com versões diferentes, engim.. Dois estímulos externos diferentes utilizando um mesmo caso de uso. Sobre o acoplamento com framework, por volta do minuto 9:30, desafio qualquer um pegar uma aplicação que não seguiu qualquer tipo de filosofia domain centric e mudar o framework dela, seja de Spring para Quarkus, de Quarkus para Micronaut, sem "problemas". Tivemos uma experiência aqui no trabalho de mudar mais de mil apps do SparkJava para Javalin e as apps que não seguiram alguma filosofia dessa quase todas precisaram ser re-escritas dada complexidade. Sobre colocar statusCode em exceptions, por volta do minuto 18:20, de fato acontece, principalmente quando o time é mais junior (mas n deveria mesmo) kkk. Sobre o código exibido, imagino como o dev junior não sofre para contribuir com esse tipo de projeto.. pegar uma simples task como validar algum header ou qualquer alteração pequena relacionada ao transport/apresentação dos dados não ficou complexa com alta carga cognitiva. Agora o dev precisa ver entender de EntityManager, entender toda a complexidade da regra de negócio, obtenção de dados da request e output tudo no mesmo lugar. Apesar de discordar muito dos pontos, seus pontos são sempre excelentes. Gosto muito de seus vídeos, Alberto!
Opa, demais! Eu cito no vídeo que o reuso proposto sobre estímulos :). Aí cito que o argumento comum é múltiplos estímulos. Só para eu entender, dentro da sua experiência isso realmente é normal? Seria um motivo razoável. Não que não pudesse ser feito sob demanda. Sobre o seu caso de migração, qual seria a dificuldade migrar se as apps seguissem a filósofa do vídeo? Confesso que este caso de migração me parece que uma ferramenta consegue automatizar boa parte do processo. Sobre complexidade de dados da request, nos fws modernos, eu sinto que não tem mais. Também falo isso no vídeo. Quando falo de camadas potencialmente desnecessárias, são justamente camadas que não adicionam nenhuma ou pouca inteligência e ainda nos obrigam a construir boilerplate para suporta-las. Lá atrás, tinha mesmo trabalho de pegar dados de request, transformar e não sei o que. Os fws hoje abstraem tudo isso, pelo menos os que entendo como bons. Essa thread aqui tá ficando legal demais.
Que baita aula Alberto, pra chegar esse nível, foram anos de estudos hem..kkk?.fiquei boquiaberto aqui.., ainda vai sobrar tempo pra eu dar uma olhada no teu treinamento. O que seria de nós se não existisse as abstrações?.. "envolver" os fluxos de negócios no centro do hexágono, deixando o mais agnóstico possível de dependências tecnológicas, enfim, o mais limpo.., promove um código que tende a sobreviver por mais tempo., apesar que código é um ser "vivo",. pois a medida em que tudo que está ao seu redor evolui..(poder computacional, etc..etc), exige que o mesmo não fique acomodado para eternidade(e se ficasse..teriamos uma mumia sendo despertada e causando terror na vida de seus mantenedores), resumindo, codigo é igual leite, com tempo estraga, aliás com muito pouco tempo está estragando, dado a velocidade com que as coisas estão acontecendo. Não vejo problema nenhum reduzir a complexidade de camadas de maneira justificada, ou o contrário seria mais correto, tem que ter uma boa justificativa pra introduzir uma nova camada, o que se pretende isolar? quais são as estratégias de mapeamento para que uma camada consiga conversar com a outra(Logical Layer), seguindo um "protocolo diplomatico"? eu posso dentro do meu domain jogar uma Exception do tipo RestException, que extend RuntimeException, com alguns parametros a mais.tal como o httpstatus? Posso até fazer isso, mas vou trazer dependências do controller(ele vive na borda, é o atalaia do ecossistema e faz contato "diplomatico" usando diversos protocolos com outras bordas,.sob http/http2 usando "lingua" json,xml..caracterizando comunicacao distribuida, N-Tier,. camadas fisicas se conversando.. ) pra dentro do meu businessCore, é pecado isso? claro que não.,só vai gerar um acoplamento a mais, sendo que poderiamos jogar um exception de Domain,. e a mesma ser interceptada em um Handler, que teria o papel de escrever a resposta/payload desejado.. ou seja,. você jamais verá um Domain invocando um método do teu controlador,. existe uma lógica.. e um fluxo a ser respeitado..o teu Domain,. pode sim obter informações de uma porta de saida(output),. e graças aquilo que chamamos de abstração,.(uso controlado da INDIREÇÃO não mata..,mas com parcimonia) não precisa o Domain conhecer a origem da solicitação, pra isso usamos interfaces, pois tanto faz.. vir de um DBMS ou de um BROKEN..esses níveis de isolamento, sobretudo com uso de Dependency Injection, é uma mão na roda pra testabilidade, principalmente quando se pretende isolar as dependencias dos componentes com uso de Mocks, esse é um desafio corriqueiro, pois testar a aplicação integrando todas interdependências, é o melhor dos mundos, mas nem sempre temos a nossa disposição todo ecossistema, ja que a ideia é testar a menor unidade de código possível. Resumindo, o grande desafio hoje, é escrever código que seja testável. Eu posso implementar o Chain Of Responsabilitity pra validar uma cadeia de condicionantes, por exemplo e um fluxo de incidência de tributos, onde tenho cpf do contribuinte, e dependendo da situação do mesmo, podera incidir o tributo x, y, z ....N, enfim, se eu fizer com que meu componente inicial a ser chamado,conheça o próximo, e o próximo conheça o proximo..etc, instanciando diretamente, a testabilidade desse fluxo vai ser dificultada(pois como vou injetar uma instância fake?, ate posso fazer isso com código extremamente intrusivo.,com uso de reflexao, mas não vejo como boa prática), mas se eu abstrair, fazendo com que cada componente receba via DIP, o proximo componente, no caso a interface, fica simples realizar o teste unitário de maneira isolada de cada componente do meu grupo de validators.
Opa, valeu demais pelo comentário! Deixando a thread cada vez mais rica. Sobre isolamento, acho que realmente depende. Como disso, existem tecnologias que são fundacionais no sistema e, dessas em específico, não vejo muita necessidade mesmo. Existem tecnologias que são mais de momento e aí acho ok me isolar dessas. Sobre testabilidade, realmente vai depender. Como mostrei aí no vídeo, meu código é testável de qualquer maneira. Inclusive peguei uma lógica mais complexa mesmo, mostrando que dá para ficar bem ok.
Concordo com muito da sua explicação e principalmente no ponto de escolher a tecnologia que será utilizada, só mantenho meu pensamento ainda sobre deixar de utilizar exceptions como controle de fluxo. Compartilho 100% a respeito dos frameworks do ecossistema java (spring/quarkus/micronaut) são excelentes e cada vez melhores. Porém há uma troca que os times esquecem. E se trata de conhecer muito bem seu ferramental. É incrivel a quantidade de pessoas usando spring, que reescreve várias das funcionalidades que ele já provê, cliente http, servlet de metricas, contadores de login, controle de acesso etc... E como a pressão chega e as pessoas acham perca de tempo ler a documentação, para fazer algo que elas já sabem fazer de forma XPTO, e acabam brigando com o framework. No final tbm vejo assim, use camadas necessárias, e quando escolher uma tecnologia estude muito bem essa tecnologia/ferramenta.
Opa, valeu demais pelo comentário. Enxergo da mesma maneira, tem que sugar tudo que pode da tecnologia. Entendo que precisamos consumir a documentação de maneira proativa mesmo!
Muito boa essa provocação. Eu sou novo nesse mundo dev, tenho um pouco mais de 2 anos de XP e hoje faço parte de um projeto que está sendo reescrito com Kotlin/Spring Boot em vários microsserviços. E eu sempre me pergunto e também aos meus colegas, para quê tanta complexidade em serviços pequenos, a liderança resolveu separar tudo em 3 módulos, para cada serviço que vamos reescrever: API, Core e DataProvider... É um trampo danado para fazer algo simples, interfaces que na maioria das vezes tem apenas um método definido... Quem sou eu na fila do pão para achar que é errado, mas na minha cabeça não entra o fato dessa complexidade toda para algo tão pequeno, o porquê desse tanto de camadas desnecessárias.
Eles estão querendo explicitamente , fazer com que você ( ou time junior , pleno ) não misture códigos em locais errados ... E criando uma separação física. Em uma troca de framework, eles podem arrancar fora por exemplo a camada de API. Mas pra min, no dia que a empresa decide mudar de framework , alguma merda aconteceu e muita das vezes o produto também mudoum.. a empresa mudou ... E às vezes o custo de re-escrever pode ser até melhor.
Parabéns pelo vídeo, Alberto. Porém, tenho alguns pontos a comentar: Entendi o seu ponto e, no seu código específico, realmente não vejo problemas. Mas permita-me discordar de alguns pontos: 1- Deixar camadas com nomes e responsabilidades definidas, seja em Services, Repository, Controllers etc., facilita a manutenção do código, pois diminui a carga cognitiva quando outros desenvolvedores forem buscar algo no código que não conhecem. Entendi que você não é contra as camadas, mas, em um projeto com vários desenvolvedores, se eu criar de uma forma e outro de outra, onde fica o padrão? 2- Sobre a clean architecture, não discordo; realmente, há muitos projetos com várias camadas desnecessárias e também módulos do Maven usados de forma desnecessária apenas para "separar" a lógica de negócio no core da aplicação. Acredito que aplicando apenas o modelo rico e as camadas como Service, Repository etc., são suficientes para manter um projeto minimamente padronizado. 3- A classe que você mencionou (Controller) está bem simples mesmo. Se isso tornar-se um padrão em seu time e o time decidir seguir assim, vejo zero problema. Enfim, não tenho muito mais a comentar. Parabéns pelo excelente vídeo!
Opa, massa ter você por aqui! 1. Ah, eu enxergo da mesma forma sobre padronização de nomes. E também concordo sobre ter um guia que direciona a organização do código seguindo o que a empresa/time entende o que é legal. 2. Realmente acho que a camada "Service" é desnecessária nos dias atuais para implementar a grande maioria das funcionalidades. Como falei no vídeo o custo dela não é só uma camada mais, vem cheio de criações adicionais para sustentar o desacoplamento. Valeu demais pelo comentário.
Sem dúvida, isso aparece até no exemplo do vídeo. Ao mesmo tempo entendo que se não reaproveitamento ou visão que vai ser necessário, não precisa separar proativamente.
Honestamente, isso não parece fazer sentido para mim. O controlador e para lidar com a resposta http. Esse mesmo código poderia ser escrito em um serviço ou algo parecido sem aumentar a complexidade percebida. Além disso, testar pode até ser possível, dependendo de como o código foi escrito, mas não é mais fácil de fazer. O número de mocks pode aumentar significativamente para escrever o mesmo teste, por exemplo. Outra coisa, esse tipo de implementação tende a se deteriorar mais rápido com o tempo dependendo da senioridade da equipe. Se você tem muitos juniores, a chance de fazer bagunça é muito maior no código cujas responsabilidades não ficam tão explicitas. Os juniores geralmente pensam muito mais na implementação do que no design, inclusive copiando o design de features semelhantes que outros desenvolvedores mais experientes da equipe fizeram. E quando esse design não é tão explícito, a chance de errar é grande. Quanto mais o fluxo aumenta de complexidade mais este codigo cresce e , por experiência própria, da manutencao no controller de 6mil linhas (nao e exagero) e um inferno.
Opa Everton, muito obrigado pela resposta! Sobre complexidade percebida, concordo. A complexidade percebida é influenciada diretamente pelo que a pessoa já sabe, está acostumada etc. Sobre o teste, pelo menos no estado atual das coisas, enxergo diferente. Em frameworks realmente bons, estilo o spring, você não precisa de mais mocks para testar isoladamente um código no controller do que você precisaria para testar o código numa camada intermediária... Mas sim, depende muito da qualidade da tecnologa... Se ela exigir um monte de coisa antes da gente poder escrever o código de negócio mesmo, aí é outra história. Sobre o crescimento da complexidade, realmente é algo que considero inerente do código. Só que aí, para mim, independe do local. Do mesmo jeito que você já viu controller com 6k linhas, eu já também já vi services hehe. Foi até por isso que criei a teoria do Cognitive Driven Development para controlar mais facilmente a complexidade. Tem vários vídeos sobre aqui no canal :).
Acredito que a maior vantagem de se criar uma camada extra para casos de usos ou serviços de aplicação não é a possibilidade futura de reuso mas de tornar explícita a intenção do usuário e orquestrar de forma mais organizada o código necessário para alcançar esse objetivo. Isso pode ser organizado em um controller mas, na minha humilde opinião, o custo de uma camada extra se paga. Outra vantagem é separar código de infraestrutura do código de negócio. É menos esforço cognitivo ao analisar uma regra de negócio! Um outro ponto que você citou é que o uso da camada de serviços traz a necessidade de se criar outros elementos para entrada e saída de dados. Eu discordo desse ponto pois nem sempre é necessário criar um elemento de forma explícita. Existem inúmeras linguagens que possuem estruturas de dados que trazem essa facilidade de forma implícita. Você pode retornar um objeto em JavaScript ou um array em PHP sem a necessidade de se criar um DTO de retorno, por exemplo. Por fim, concordo contigo de EVITAR CAMADAS DESNECESSÁRIAS por adicionar mais complexidade ao código e ser potenciais pontos de falha. Mas a camada de serviço ou caso de uso eu julgo, quase sempre, necessária. Principalmente em operações que alteram o estado do servidor. Considero, porém, que seja dispensável quando trata-se apenas de um proxy para o acesso a dados. Aprendi que não devemos seguir padrões ou processos "by the book" e sem uma análise crítica. Mas entendo também que certos trade-offs de padrões arquiteturais conhecidos são válidos de acordo com o contexto. ;) Observação: achei que a ênfase que você deu em "frameworks bons" repetidamente e a associação com Spring pode soar meio depreciativo com quem usa outros frameworks. ;P
Opa, valeu demais pelo comentário! Vou deixar minha resposta começando pelo final :). Vou deixar o pedido de desculpas sobre depreciar outros FWs... Não quis passar essa impressão, mas se passou, quer dizer que errei o tom. Já fui usuário de outros, principalmente o Rails (que considero a grande inovação neste mundo considerando o tempo que programo). Sobre separação de código e relação com intenção e carga cognitiva, enxergo diferente realmente. Para mim um arquivo com uma classe que chama ExecutaPagamentoComCartaoController passa a intenção. Sobre entendimento, também não vejo como mover um código inteiro de um lugar para outro ajuda, ainda mais se for mover literalmente o corpo da classe inteiro, que seria o caso aí. Será que não é mais costume com um padrão do que um real ganho? Sobre a camada intermediária retornar uma estrutura pronta como um Objeto Literal ou um Array, aí eu tenho uma pergunta. Supondo que este método aí do meio retornou um Array, como que o ponto chamador(controller) sabe quais informações tem lá dentro? Assumo aqui que o controller não pode simplesmente retornar o objeto literal ou array como resposta, ele precisa analisar ali o que de fato precisa ser devolvido.
O comentário é bom , só o exemplo do javascript e do PHP que foram infortúnuos... São péssimos exemplos de design , não dão visibilidade nem clareza ... A não ser que você esteja debutando em rumtine ...
Excelente video! Justo neste momento estou iniciando um projeto de app em Flutter, que faz requisições HTTP para a API da empresa, e estou perdendo muito tempo decidindo qual a melhor arquitetura. Quais camadas voce considera essenciais?
Considero essenciais apenas as que são de fato obrigatórias dada a escolha das tecnologias. Confesso que não sei o estado do flutter quando falamos de validação de dados de entrada, transformação dos valores da tela para a abstração que você vai querer usar para enviar tais dados para outros serviços etc.. Se for um estado de maturidade estilo Spring MVC e outros, faria como mostrei no vídeo. Se não for, talvez valha a pena sim dividir o código.
Acho q fui reprovado na promoção por não usar clean arquiteture/DDD e por não saber AWS que eu não uso no trabalho. E vc, q pra min é uma referência falando que tem muitas coisas que são desnecessárias KKK Concordo pequenos código, poucas regras de negócio não precisa desse Domain model. Mas talvez valha a pena pra casos maiores, pois são n pessoas que vão usar e n anos com o código produtivo. Teria que ter um padrão de mercado pra todos conseguirem seguir sem muitos problemas e deixar o código no mesmo padrão. Daí acho q as camadas a mais valem a pena.
Pensei nisso também, se é uma arquitetura de micro serviço, por que tanta complexidade 😂, mvc já não dá conta de micro serviço 😂, brincadeira a parte, entendo que tem casos que é necessário
Opa, valeu demais pelo comentário. Sobre seguir o padrão de mercado... Não vejo motivos para seguir se tem mais custo do que benefício, para ser sincero. Tirar uma camada possivelmente desnecessária do meio não é uma mudança radical e imagino que não causaria muito impacto para quem chega :). E concordo que o software vai ficar lá por anos e que precisa ser escrito de tal maneira que a manutenção seja facilitada, só não acho que as ideias destes tipos de arquitetura estejam contribuindo para isso hehe.
Meu mundo é o dotnet não Java, talvez no ecossistema Java as coisas sejam mais complicadas que no meu dia a dia. Disclaimer feito, eu concordo contigo quando estamos falando de um fluxo claro de receber algo de algum lugar e que não altera estado e direciona esse dado para outro lugar para ser persistido. Agora, se existe uma mudança de estado da minha entidade, para mim, isso deveria ser tratado fora da camada de apresentação. Afinal, no meu ponto de vista, uma controller (no caso de API) tem a única responsabilidade que é tratar chamadas Http (requests e responses) e em caso de exceptions essas mesmas serão desse contexto. Para mim é mais uma questão de separação de responsabilidades e diminuir o ruído no entendimento do código e quando movo regras para fora do controller e uso abstrações isso me ajuda muito. Tanto para testar, pois preciso só me concentrar no controller (entrada e saída) e não no resto. O argumento de que a criação de camadas pode causar lentidão no processo de desenvolvimento para mim não é a causa da lentidão, muitas vezes falta de criação de códigos coesos e pouco acoplados e sem uso de abstrações. Criar um arquivo a mais, um arquivo de teste a mais, não deveria ser um problema ao ponto de gerar lentidão perceptível no processo de desenvolvimento. E sobre o uso da exception, acho o uso válido quando no fluxo que o dado percorre, caso ocorra um erro é o responsável pelo início desse fluxo não tem mais a possibilidade de recuperar para um estado válido o dado, a exception deve ser jogada. Mas se meu fluxo permite a recuperação do dado para um estado valido, o uso de mecanismos de notificação devem ser usados para informar à quem iniciou o processo realizar a alteração do dado para um estado válido.
Oi Bruno, obrigado pela resposta, massa! Sobre o que você trouxe. Eu realmente não acho que criar mais arquivos é sinônimo de lentidão, mas quando falamos de camadas intermediárias, estamos falando de mais abstrações para sustentar essa decisão inicial. Ter que desacoplar do ponto de entrada o tempo inteiro, na minha visão, gera esforço a mais. E nem sempre é fácil ficar desconsiderando a fonte de entrada... Sobre a visão que o controller deveria tratar requisições considero que, no estado atual das coisas, tal visão pode ser modificada. Acho que essa separação de responsabilidade era importante quando os controllers web realmente expunham um monte de coisa http.. Hoje em dia, a exposição é mínima, dada a evolução das tecnologias. Como falei no vídeo, é quase que zero intrusivo. Sobre entendimento realmente é algo contextual, se todo mundo esperar encontrar um Service, pode dificultar o entendimento.. Se todo mundo espera encontrar a versão mais direta do código, isso deixa de ser motivo de fricção.
Para mim, esses hypes como Clean Arch, Hexagonal e outras, são formas de "forçar" a aplicação de estratégias de design para quem não aprendeu fundo os conceitos básicos de OOP. Simples assim.
Opa Carlos, confesso que tenho uma visão menos "dura" sobre o uso.. Tenho uma impressão que algumas das ideias ali meio que dataram, principalmente de ficar totalmente desacoplado das tecnologias.
Também concordo Carlos, lógico que elas refinam alguns conceitos, pra poder emplacar a ideia de algo novo e revolucionário. Mais 80% do fundamento é OOP, que está por trás ... 20% ou menos são algumas contribuições para os novos desafios e visões.
Temos um treinamento cujo objetivo é fazer com que você escreva código de qualidade independente da situação.
Entendemos que aplicar as boas práticas com fluidez é o caminho mais interessante para que você consiga acelerar suas entregas gerando cada vez mais valor.
Acesse em deveficiente.com
Eu adoro quando você fala "você vai ter que mexer e tá tudo bem...". Uma lição massa que aprendi com meu atual diretor foi "A gente de engenharia fica pensando demais em como fazer perfeito sendo que a solução que a gente entrega é software, é maleável, se der errado, refatora..."
Valeu demais pelo comentário! Eu realmente acredito o princípio do Open Closed de vez em quando coloca um peso extra... Modificar não precisa ser um problema.
Muito bom Alberto, mais do que seguir uma padrão ou o que quer que seja o código tem que fazer sentido. Na minha opinião a ideia de uma arquitectura limpa ou hexagonal se preferir, facilita muito na reconstrução da idea por um Dev que não é o mesmo que escreveu o código. Resumindo o código tem que ficar claro e facil para qual quer Dev. Acho que esse é o ponto. como garantir isso ? Depende kkk. muito bom o video
Massa que curtiu!
Opa, Alberto! Ótimos pontos. Concordo que devemos ter um olhar crítico sobre a quantidade excessiva de camadas, que muitas vezes são desnecessárias e acabam trazendo mais complexidade e custo de manutenção. Um ponto que considero é que, geralmente, temos times de engenharia com diferentes senioridades , e tomar "decisões coesas" para componentes de software ou se adicionamos ou não uma camada, exige experiência e um bom entendimento do domínio, competências que desenvolvedores menos experientes ainda estão construindo. Ao definir uma estrutura com N camadas e explicar que vamos utilizar um 'padrão' de mercado, talvez seja mais fácil orientar e estudar o que é cada uma. E, embora isso não nos garanta ter software melhores, sei que ao olhar para uma camada de serviço, encontrarei regras de negócio, quando olhar para um controller sei que vou ter: solicitações http, entrada de dados, alguma chamada para validar essa entrada... etc . Quando não temos isso bem definido, exige uma comunicação e documentação muito bem estruturadas no time; algo que geralmente não está disponível no início do projeto e pode levar tempo para ser desenvolvido. Como você vê esse ponto?
Opa Cleyton, eu adoro guidelines :). Considero que são fundamentais para fazer isso que você citou mesmo, trazer algum padrão para o desenvolvimento. Neste caso minha sugestão seria mudar o guideline :).
É como você falou, pensando em código, deslocar praticamente 100% do código de uma camada para outra não facilita nada... E meio que é isso acontece dada a maturidade das tecnologias de apoio hoje em dia.
Sobre os casos de uso vs reutilização, por volta do minuto 6:40, o que a literatura fala sobre reutilização não é do ponto de vista de um caso de uso chamando o outro (isso não deveria acontecer), é do ponto de vista dos estímulos externos que executam o caso de uso. Esse é o reaproveitamento. É bastante comum ter um caso de uso que é executado por um estímulo de mensageria e também expor o mesmo via endpoint http para utilizar via scripts, por exemplo, ou que recebe via GRPC e tb REST, ou até mesmo dois endpoints rest mas com versões diferentes, engim.. Dois estímulos externos diferentes utilizando um mesmo caso de uso.
Sobre o acoplamento com framework, por volta do minuto 9:30, desafio qualquer um pegar uma aplicação que não seguiu qualquer tipo de filosofia domain centric e mudar o framework dela, seja de Spring para Quarkus, de Quarkus para Micronaut, sem "problemas". Tivemos uma experiência aqui no trabalho de mudar mais de mil apps do SparkJava para Javalin e as apps que não seguiram alguma filosofia dessa quase todas precisaram ser re-escritas dada complexidade.
Sobre colocar statusCode em exceptions, por volta do minuto 18:20, de fato acontece, principalmente quando o time é mais junior (mas n deveria mesmo) kkk.
Sobre o código exibido, imagino como o dev junior não sofre para contribuir com esse tipo de projeto.. pegar uma simples task como validar algum header ou qualquer alteração pequena relacionada ao transport/apresentação dos dados não ficou complexa com alta carga cognitiva. Agora o dev precisa ver entender de EntityManager, entender toda a complexidade da regra de negócio, obtenção de dados da request e output tudo no mesmo lugar.
Apesar de discordar muito dos pontos, seus pontos são sempre excelentes. Gosto muito de seus vídeos, Alberto!
Opa, demais!
Eu cito no vídeo que o reuso proposto sobre estímulos :).
Aí cito que o argumento comum é múltiplos estímulos. Só para eu entender, dentro da sua experiência isso realmente é normal? Seria um motivo razoável. Não que não pudesse ser feito sob demanda.
Sobre o seu caso de migração, qual seria a dificuldade migrar se as apps seguissem a filósofa do vídeo? Confesso que este caso de migração me parece que uma ferramenta consegue automatizar boa parte do processo.
Sobre complexidade de dados da request, nos fws modernos, eu sinto que não tem mais. Também falo isso no vídeo.
Quando falo de camadas potencialmente desnecessárias, são justamente camadas que não adicionam nenhuma ou pouca inteligência e ainda nos obrigam a construir boilerplate para suporta-las.
Lá atrás, tinha mesmo trabalho de pegar dados de request, transformar e não sei o que. Os fws hoje abstraem tudo isso, pelo menos os que entendo como bons.
Essa thread aqui tá ficando legal demais.
Que baita aula Alberto, pra chegar esse nível, foram anos de estudos hem..kkk?.fiquei boquiaberto aqui.., ainda vai sobrar tempo pra eu dar uma olhada no teu treinamento. O que seria de nós se não existisse as abstrações?.. "envolver" os fluxos de negócios no centro do hexágono, deixando o mais agnóstico possível de dependências tecnológicas, enfim, o mais limpo.., promove um código que tende a sobreviver por mais tempo., apesar que código é um ser "vivo",. pois a medida em que tudo que está ao seu redor evolui..(poder computacional, etc..etc), exige que o mesmo não fique acomodado para eternidade(e se ficasse..teriamos uma mumia sendo despertada e causando terror na vida de seus mantenedores), resumindo, codigo é igual leite, com tempo estraga, aliás com muito pouco tempo está estragando, dado a velocidade com que as coisas estão acontecendo. Não vejo problema nenhum reduzir a complexidade de camadas de maneira justificada, ou o contrário seria mais correto, tem que ter uma boa justificativa pra introduzir uma nova camada, o que se pretende isolar? quais são as estratégias de mapeamento para que uma camada consiga conversar com a outra(Logical Layer), seguindo um "protocolo diplomatico"? eu posso dentro do meu domain jogar uma Exception do tipo RestException, que extend RuntimeException, com alguns parametros a mais.tal como o httpstatus? Posso até fazer isso, mas vou trazer dependências do controller(ele vive na borda, é o atalaia do ecossistema e faz contato "diplomatico" usando diversos protocolos com outras bordas,.sob http/http2 usando "lingua" json,xml..caracterizando comunicacao distribuida, N-Tier,. camadas fisicas se conversando.. ) pra dentro do meu businessCore, é pecado isso? claro que não.,só vai gerar um acoplamento a mais, sendo que poderiamos jogar um exception de Domain,. e a mesma ser interceptada em um Handler, que teria o papel de escrever a resposta/payload desejado.. ou seja,. você jamais verá um Domain invocando um método do teu controlador,. existe uma lógica.. e um fluxo a ser respeitado..o teu Domain,. pode sim obter informações de uma porta de saida(output),. e graças aquilo que chamamos de abstração,.(uso controlado da INDIREÇÃO não mata..,mas com parcimonia) não precisa o Domain conhecer a origem da solicitação, pra isso usamos interfaces, pois tanto faz.. vir de um DBMS ou de um BROKEN..esses níveis de isolamento, sobretudo com uso de Dependency Injection, é uma mão na roda pra testabilidade, principalmente quando se pretende isolar as dependencias dos componentes com uso de Mocks, esse é um desafio corriqueiro, pois testar a aplicação integrando todas interdependências, é o melhor dos mundos, mas nem sempre temos a nossa disposição todo ecossistema, ja que a ideia é testar a menor unidade de código possível. Resumindo, o grande desafio hoje, é escrever código que seja testável. Eu posso implementar o Chain Of Responsabilitity pra validar uma cadeia de condicionantes, por exemplo e um fluxo de incidência de tributos, onde tenho cpf do contribuinte, e dependendo da situação do mesmo, podera incidir o tributo x, y, z ....N, enfim, se eu fizer com que meu componente inicial a ser chamado,conheça o próximo, e o próximo conheça o proximo..etc, instanciando diretamente, a testabilidade desse fluxo vai ser dificultada(pois como vou injetar uma instância fake?, ate posso fazer isso com código extremamente intrusivo.,com uso de reflexao, mas não vejo como boa prática), mas se eu abstrair, fazendo com que cada componente receba via DIP, o proximo componente, no caso a interface, fica simples realizar o teste unitário de maneira isolada de cada componente do meu grupo de validators.
Opa, valeu demais pelo comentário! Deixando a thread cada vez mais rica.
Sobre isolamento, acho que realmente depende. Como disso, existem tecnologias que são fundacionais no sistema e, dessas em específico, não vejo muita necessidade mesmo.
Existem tecnologias que são mais de momento e aí acho ok me isolar dessas.
Sobre testabilidade, realmente vai depender. Como mostrei aí no vídeo, meu código é testável de qualquer maneira. Inclusive peguei uma lógica mais complexa mesmo, mostrando que dá para ficar bem ok.
Concordo com muito da sua explicação e principalmente no ponto de escolher a tecnologia que será utilizada, só mantenho meu pensamento ainda sobre deixar de utilizar exceptions como controle de fluxo.
Compartilho 100% a respeito dos frameworks do ecossistema java (spring/quarkus/micronaut) são excelentes e cada vez melhores.
Porém há uma troca que os times esquecem. E se trata de conhecer muito bem seu ferramental.
É incrivel a quantidade de pessoas usando spring, que reescreve várias das funcionalidades que ele já provê, cliente http, servlet de metricas, contadores de login, controle de acesso etc...
E como a pressão chega e as pessoas acham perca de tempo ler a documentação, para fazer algo que elas já sabem fazer de forma XPTO, e acabam brigando com o framework.
No final tbm vejo assim, use camadas necessárias, e quando escolher uma tecnologia estude muito bem essa tecnologia/ferramenta.
Opa, valeu demais pelo comentário. Enxergo da mesma maneira, tem que sugar tudo que pode da tecnologia. Entendo que precisamos consumir a documentação de maneira proativa mesmo!
Muito boa essa provocação. Eu sou novo nesse mundo dev, tenho um pouco mais de 2 anos de XP e hoje faço parte de um projeto que está sendo reescrito com Kotlin/Spring Boot em vários microsserviços. E eu sempre me pergunto e também aos meus colegas, para quê tanta complexidade em serviços pequenos, a liderança resolveu separar tudo em 3 módulos, para cada serviço que vamos reescrever: API, Core e DataProvider... É um trampo danado para fazer algo simples, interfaces que na maioria das vezes tem apenas um método definido... Quem sou eu na fila do pão para achar que é errado, mas na minha cabeça não entra o fato dessa complexidade toda para algo tão pequeno, o porquê desse tanto de camadas desnecessárias.
Neste contexto que você explicou, enxergo de maneira parecida.
Eles estão querendo explicitamente , fazer com que você ( ou time junior , pleno ) não misture códigos em locais errados ... E criando uma separação física.
Em uma troca de framework, eles podem arrancar fora por exemplo a camada de API.
Mas pra min, no dia que a empresa decide mudar de framework , alguma merda aconteceu e muita das vezes o produto também mudoum.. a empresa mudou ... E às vezes o custo de re-escrever pode ser até melhor.
Parabéns pelo vídeo, Alberto. Porém, tenho alguns pontos a comentar:
Entendi o seu ponto e, no seu código específico, realmente não vejo problemas. Mas permita-me discordar de alguns pontos:
1- Deixar camadas com nomes e responsabilidades definidas, seja em Services, Repository, Controllers etc., facilita a manutenção do código, pois diminui a carga cognitiva quando outros desenvolvedores forem buscar algo no código que não conhecem. Entendi que você não é contra as camadas, mas, em um projeto com vários desenvolvedores, se eu criar de uma forma e outro de outra, onde fica o padrão?
2- Sobre a clean architecture, não discordo; realmente, há muitos projetos com várias camadas desnecessárias e também módulos do Maven usados de forma desnecessária apenas para "separar" a lógica de negócio no core da aplicação. Acredito que aplicando apenas o modelo rico e as camadas como Service, Repository etc., são suficientes para manter um projeto minimamente padronizado.
3- A classe que você mencionou (Controller) está bem simples mesmo. Se isso tornar-se um padrão em seu time e o time decidir seguir assim, vejo zero problema.
Enfim, não tenho muito mais a comentar. Parabéns pelo excelente vídeo!
Opa, massa ter você por aqui!
1. Ah, eu enxergo da mesma forma sobre padronização de nomes. E também concordo sobre ter um guia que direciona a organização do código seguindo o que a empresa/time entende o que é legal.
2. Realmente acho que a camada "Service" é desnecessária nos dias atuais para implementar a grande maioria das funcionalidades. Como falei no vídeo o custo dela não é só uma camada mais, vem cheio de criações adicionais para sustentar o desacoplamento.
Valeu demais pelo comentário.
O caso de uso inteiro não pode ser reaproveitável, mas vc pode dividir o escopo do caso de uso em componentes reaproveitáveis
Sem dúvida, isso aparece até no exemplo do vídeo. Ao mesmo tempo entendo que se não reaproveitamento ou visão que vai ser necessário, não precisa separar proativamente.
Boa provocação!
Legal que curtiu!
Honestamente, isso não parece fazer sentido para mim. O controlador e para lidar com a resposta http. Esse mesmo código poderia ser escrito em um serviço ou algo parecido sem aumentar a complexidade percebida. Além disso, testar pode até ser possível, dependendo de como o código foi escrito, mas não é mais fácil de fazer. O número de mocks pode aumentar significativamente para escrever o mesmo teste, por exemplo. Outra coisa, esse tipo de implementação tende a se deteriorar mais rápido com o tempo dependendo da senioridade da equipe. Se você tem muitos juniores, a chance de fazer bagunça é muito maior no código cujas responsabilidades não ficam tão explicitas. Os juniores geralmente pensam muito mais na implementação do que no design, inclusive copiando o design de features semelhantes que outros desenvolvedores mais experientes da equipe fizeram. E quando esse design não é tão explícito, a chance de errar é grande. Quanto mais o fluxo aumenta de complexidade mais este codigo cresce e , por experiência própria, da manutencao no controller de 6mil linhas (nao e exagero) e um inferno.
Obs : concordo que abstracoes devem surgir da necessidade
Opa Everton, muito obrigado pela resposta!
Sobre complexidade percebida, concordo. A complexidade percebida é influenciada diretamente pelo que a pessoa já sabe, está acostumada etc.
Sobre o teste, pelo menos no estado atual das coisas, enxergo diferente. Em frameworks realmente bons, estilo o spring, você não precisa de mais mocks para testar isoladamente um código no controller do que você precisaria para testar o código numa camada intermediária... Mas sim, depende muito da qualidade da tecnologa... Se ela exigir um monte de coisa antes da gente poder escrever o código de negócio mesmo, aí é outra história.
Sobre o crescimento da complexidade, realmente é algo que considero inerente do código. Só que aí, para mim, independe do local. Do mesmo jeito que você já viu controller com 6k linhas, eu já também já vi services hehe. Foi até por isso que criei a teoria do Cognitive Driven Development para controlar mais facilmente a complexidade. Tem vários vídeos sobre aqui no canal :).
6k linhas no controller significa que alguém escreveu código no local errado. 😅
Acredito que a maior vantagem de se criar uma camada extra para casos de usos ou serviços de aplicação não é a possibilidade futura de reuso mas de tornar explícita a intenção do usuário e orquestrar de forma mais organizada o código necessário para alcançar esse objetivo.
Isso pode ser organizado em um controller mas, na minha humilde opinião, o custo de uma camada extra se paga. Outra vantagem é separar código de infraestrutura do código de negócio. É menos esforço cognitivo ao analisar uma regra de negócio!
Um outro ponto que você citou é que o uso da camada de serviços traz a necessidade de se criar outros elementos para entrada e saída de dados. Eu discordo desse ponto pois nem sempre é necessário criar um elemento de forma explícita.
Existem inúmeras linguagens que possuem estruturas de dados que trazem essa facilidade de forma implícita. Você pode retornar um objeto em JavaScript ou um array em PHP sem a necessidade de se criar um DTO de retorno, por exemplo.
Por fim, concordo contigo de EVITAR CAMADAS DESNECESSÁRIAS por adicionar mais complexidade ao código e ser potenciais pontos de falha.
Mas a camada de serviço ou caso de uso eu julgo, quase sempre, necessária. Principalmente em operações que alteram o estado do servidor. Considero, porém, que seja dispensável quando trata-se apenas de um proxy para o acesso a dados.
Aprendi que não devemos seguir padrões ou processos "by the book" e sem uma análise crítica. Mas entendo também que certos trade-offs de padrões arquiteturais conhecidos são válidos de acordo com o contexto. ;)
Observação: achei que a ênfase que você deu em "frameworks bons" repetidamente e a associação com Spring pode soar meio depreciativo com quem usa outros frameworks. ;P
Opa, valeu demais pelo comentário! Vou deixar minha resposta começando pelo final :).
Vou deixar o pedido de desculpas sobre depreciar outros FWs... Não quis passar essa impressão, mas se passou, quer dizer que errei o tom. Já fui usuário de outros, principalmente o Rails (que considero a grande inovação neste mundo considerando o tempo que programo).
Sobre separação de código e relação com intenção e carga cognitiva, enxergo diferente realmente. Para mim um arquivo com uma classe que chama ExecutaPagamentoComCartaoController passa a intenção. Sobre entendimento, também não vejo como mover um código inteiro de um lugar para outro ajuda, ainda mais se for mover literalmente o corpo da classe inteiro, que seria o caso aí. Será que não é mais costume com um padrão do que um real ganho?
Sobre a camada intermediária retornar uma estrutura pronta como um Objeto Literal ou um Array, aí eu tenho uma pergunta. Supondo que este método aí do meio retornou um Array, como que o ponto chamador(controller) sabe quais informações tem lá dentro? Assumo aqui que o controller não pode simplesmente retornar o objeto literal ou array como resposta, ele precisa analisar ali o que de fato precisa ser devolvido.
O comentário é bom , só o exemplo do javascript e do PHP que foram infortúnuos... São péssimos exemplos de design , não dão visibilidade nem clareza ... A não ser que você esteja debutando em rumtine ...
Excelente video! Justo neste momento estou iniciando um projeto de app em Flutter, que faz requisições HTTP para a API da empresa, e estou perdendo muito tempo decidindo qual a melhor arquitetura. Quais camadas voce considera essenciais?
Considero essenciais apenas as que são de fato obrigatórias dada a escolha das tecnologias.
Confesso que não sei o estado do flutter quando falamos de validação de dados de entrada, transformação dos valores da tela para a abstração que você vai querer usar para enviar tais dados para outros serviços etc.. Se for um estado de maturidade estilo Spring MVC e outros, faria como mostrei no vídeo.
Se não for, talvez valha a pena sim dividir o código.
Acho q fui reprovado na promoção por não usar clean arquiteture/DDD e por não saber AWS que eu não uso no trabalho. E vc, q pra min é uma referência falando que tem muitas coisas que são desnecessárias KKK
Concordo pequenos código, poucas regras de negócio não precisa desse Domain model.
Mas talvez valha a pena pra casos maiores, pois são n pessoas que vão usar e n anos com o código produtivo. Teria que ter um padrão de mercado pra todos conseguirem seguir sem muitos problemas e deixar o código no mesmo padrão. Daí acho q as camadas a mais valem a pena.
Pensei nisso também, se é uma arquitetura de micro serviço, por que tanta complexidade 😂, mvc já não dá conta de micro serviço 😂, brincadeira a parte, entendo que tem casos que é necessário
Opa, valeu demais pelo comentário.
Sobre seguir o padrão de mercado... Não vejo motivos para seguir se tem mais custo do que benefício, para ser sincero. Tirar uma camada possivelmente desnecessária do meio não é uma mudança radical e imagino que não causaria muito impacto para quem chega :).
E concordo que o software vai ficar lá por anos e que precisa ser escrito de tal maneira que a manutenção seja facilitada, só não acho que as ideias destes tipos de arquitetura estejam contribuindo para isso hehe.
Qual repo deste código ?
github.com/asouza/jornada-desafio-checkout-hotmart
Meu mundo é o dotnet não Java, talvez no ecossistema Java as coisas sejam mais complicadas que no meu dia a dia. Disclaimer feito, eu concordo contigo quando estamos falando de um fluxo claro de receber algo de algum lugar e que não altera estado e direciona esse dado para outro lugar para ser persistido. Agora, se existe uma mudança de estado da minha entidade, para mim, isso deveria ser tratado fora da camada de apresentação. Afinal, no meu ponto de vista, uma controller (no caso de API) tem a única responsabilidade que é tratar chamadas Http (requests e responses) e em caso de exceptions essas mesmas serão desse contexto. Para mim é mais uma questão de separação de responsabilidades e diminuir o ruído no entendimento do código e quando movo regras para fora do controller e uso abstrações isso me ajuda muito. Tanto para testar, pois preciso só me concentrar no controller (entrada e saída) e não no resto. O argumento de que a criação de camadas pode causar lentidão no processo de desenvolvimento para mim não é a causa da lentidão, muitas vezes falta de criação de códigos coesos e pouco acoplados e sem uso de abstrações. Criar um arquivo a mais, um arquivo de teste a mais, não deveria ser um problema ao ponto de gerar lentidão perceptível no processo de desenvolvimento. E sobre o uso da exception, acho o uso válido quando no fluxo que o dado percorre, caso ocorra um erro é o responsável pelo início desse fluxo não tem mais a possibilidade de recuperar para um estado válido o dado, a exception deve ser jogada. Mas se meu fluxo permite a recuperação do dado para um estado valido, o uso de mecanismos de notificação devem ser usados para informar à quem iniciou o processo realizar a alteração do dado para um estado válido.
Oi Bruno, obrigado pela resposta, massa!
Sobre o que você trouxe. Eu realmente não acho que criar mais arquivos é sinônimo de lentidão, mas quando falamos de camadas intermediárias, estamos falando de mais abstrações para sustentar essa decisão inicial. Ter que desacoplar do ponto de entrada o tempo inteiro, na minha visão, gera esforço a mais. E nem sempre é fácil ficar desconsiderando a fonte de entrada...
Sobre a visão que o controller deveria tratar requisições considero que, no estado atual das coisas, tal visão pode ser modificada. Acho que essa separação de responsabilidade era importante quando os controllers web realmente expunham um monte de coisa http.. Hoje em dia, a exposição é mínima, dada a evolução das tecnologias. Como falei no vídeo, é quase que zero intrusivo.
Sobre entendimento realmente é algo contextual, se todo mundo esperar encontrar um Service, pode dificultar o entendimento.. Se todo mundo espera encontrar a versão mais direta do código, isso deixa de ser motivo de fricção.
Gosto de conteúdos assim, disruptivos...temos que parar de lero lero....
hehehe, legal que curtiu!
Para mim, esses hypes como Clean Arch, Hexagonal e outras, são formas de "forçar" a aplicação de estratégias de design para quem não aprendeu fundo os conceitos básicos de OOP. Simples assim.
Opa Carlos, confesso que tenho uma visão menos "dura" sobre o uso.. Tenho uma impressão que algumas das ideias ali meio que dataram, principalmente de ficar totalmente desacoplado das tecnologias.
Também concordo Carlos, lógico que elas refinam alguns conceitos, pra poder emplacar a ideia de algo novo e revolucionário. Mais 80% do fundamento é OOP, que está por trás ... 20% ou menos são algumas contribuições para os novos desafios e visões.