Um dica para os testes q eu particularmente achei melhor, em vez de instanciar a class a cada teste, instanciei apenas uma vez de forma global antes de todos os testes, dessa forma: const routeProps = { title: 'minha rota', startPosition: {lat: 0, lng: 1}, endPosition: {lat: 0, lng: 1}, points: [] } let globalRoute = new Route(routeProps) // só usar o "globalRoute" dentro dos testes em vez de escrever tudo isso de novo a cada teste
Caro. Estou assistindo essa ex-live depois de um ano, mas vou tentar tirar minha dúvida. São 2. A primeira é onde entraria no seu exemplo a camada que tem os controladores? Segunda dúvida. Se eu quero buscar dados de relações entre entidades, por exemplo uma query com Join, na implementação do meu repository pra qual entidade eu eu faria essa implementação?
No caso, de forma resumida: a cada de entidades ficam as regras de negócios. Já as camadas de casos de usos ficam os serviços que gerenciam essas regras de negócios, semelhantes a camada controller do MVC. A camada Core é responsável pela persistência dos dados e a última camada é para o framework, seja web, deskop, mobile etc. Está correta, professor, essa visão do modelo?
No 2:50:55 você deu um exempl de findById, como eu faria para ele retornar sempre uma promise Rota quando implementado no repositório, já que nem sempre vai existir o elemento com o ID ?
Existe alguma recomendação em usar OOP na criação de entidades envez de programação funcional? Se fosse aplicar Clean Archecture no React, acho confuso criar coisas usando OOP quando todo React usa functional programing.
Oi F4ilcon, tudo bem? Autores como Robert Martin, Vernon e Eric Evans relatam que a orientação a objetos é o que melhor se adequa a este tipo de arquitetura, mas não sendo impossível aplicar os conceitos em outros paradigma. Em linguagens funcionais a recomendação para modelar as entidades é usar as estrutura que modelam dados, já em React.js a Clean Arch não pode ser aplicada 100%, porque o objetivo do front-end não é o mesmo do back-end, além de que necessitamos que o front-end fique "preso" ao React para funcionar, mas conseguimos usar conceitos de separação de responsabilidades e SOLID para evitar que regras de negócio não fiquem embutidas dentro dos componentes.
@@argentinaluiz Perfeito a sua colocacao, acho que cai no conto de applicar clean arch em tudo(front-end), agora pesquisando vejo que nao se consegue applicar 100%, apenas o SOLID e mesmo com alguma restricao, parabens pelo conteudo, seu material eh de longe o mais esclarecedor que encontrei sobre o assunto, direto no assunto usando um exemplo bem simples.
Sobre o repository lidar com entidades, tive a mesma dúvida que o pessoal pq o uncle Bob diz (tanto no livro como no artigo do blog dele) que somente estruturas de dados simples (incluindo DTOs) podem cruzar camadas, nunca Entidades (sim, ele diz explicitamente isto). Se isto fere o conceito de repository, vale dizer que o uncle Bob no livro não cita o termo repository z e sim fala em "Gateway de banco de dados" (e interface do mesmo) de forma genérica.
What data crosses the boundaries. Typically the data that crosses the boundaries is simple data structures. You can use basic structs or simple Data Transfer objects if you like. Or the data can simply be arguments in function calls. Or you can pack it into a hashmap, or construct it into an object. The important thing is that isolated, simple, data structures are passed across the boundaries. We don’t want to cheat and pass Entities or Database rows.
Oi Felipe, tudo bem? Obrigado pelo feedback! No livro Clean Architecture, o Robert Martin menciona "Gateway" em vez de "Repository", porque um Gateway pode fazer outras coisas além de I/O, ele pode se comunicar com um sistema externo também, então seria um conceito mais abstrato. Tem algumas pessoas que realmente preferem usar Gateway no nome mesmo sendo um repositório puro na essência. Sobre a questão do que passar para o repositório/gateway quando queremos salvar, remover, criar deve ser uma entidade, porque o objetivo é lidar das entidades. O trecho que você expôs diz respeito na comunicação entre as camadas, que seriam controllers vs use cases, consumers vs use cases, cli vs use cases. Estas são camadas que estão acessados a camada de aplicação. Os repositórios são um contrato interno da camada de aplicação. Entendeu a ideia?
uai, cada caso de uso ali que ele fez é uma parte do crud(Create = create-route.use-case, Read = list-all-routes.use-case), seria só implementar as operações de atualizar e deletar como use-cases
Professor uma dúvida, foi criado uma interface chamada RouterRepositoryInterface onde nesta interface se tem os métodos de salvar e listar todas as rotas, bom estaria errado se eu criasse uma interface pra cada um dos métodos onde se facilitaria nos testes unitarios .
Olá Paulo, tudo bem? Poderíamos ter algum assim: class RouteRepositoryInterface extends InsertActionInterface, ListAllActionInterface{ } Seria uma forma de permitir que repositórios pudessem implementar somente o que necessitasse, mas isto isto mais feito para aplicações mais complexas.
Paulo posso responder a essa questão usando o principio da segregação de interfaces (ISP), caso sua interface for usado por uma classe concreta, e não implemente todos os seus métodos, você estaria ferindo o ISP! No caso não é errado criar uma interface para cada método, porém como disse, se não estiver ferindo o príncipio não vejo problema em utilizar penas uma interface para as duas ações! Abraços.
Olá Wilhams, tudo bem? Muito obrigado pelo feedback! Isto funciona, porque é do mesmo tipo que RouteProps. O TypeScript analisa os tipos verificando os tipos das propriedades, se baterem está correto!
Luiz.. eu nem trabalho mais com programação, fui apenas junior por 6 meses em actionscript(do antigo flash), sou profissional da infra, mas resolvi fazer a semana toda completa, e não entendi ainda porque tente cria um private set title e depois um update title... qual a diferença? se quer setar o titulo porque não apenas mudar o set do title para public? Ele não é um método???? e se vc faz um update tiltle qual a intenção de manter o set title como private?
Oi Volt, tudo bem? Este é uma ideia pra enriquecer a modelagem de dados. Quando usamos os setters para definir os dados eles ficariam espalhados, soltos pela aplicação sem deixar claro as intenções das regras de negócio, o que chamados de modelo anêmico, sem expressividade. O updateTitle faz sentido considerando que iremos querer atualizar o título da rota sem mexer no resto, mas isto somente se fizer sentido pro negócio, entendeu a ideia?
@@argentinaluiz Entendi sim, obrigado pela resposta... explicitar a questão do negócio, muito legal essa visão, parece que sempre deveria ter sido assim...
Olá Paulo, tudo bem? Não, a pasta controllers faz da parte infraestrutura, segunda a arquitetura hexagonal ela é um adaptador de entrada para os use cases.
It é um alias para teste, são iguais, mas fica mais descriminativo usar it describe(Resource) - it(should do something) Leia se descrever(Recurso) - isso(deve fazer alguma coisa)
Oi Henrique, tudo bem? Obrigado pelo feedback! Sim, estamos violando a Clean Arch se um caso de uso utilizar outro, porque os casos de uso obedecem ao Single Responsability Principle, ou seja, a classe tem ter apenas um motivo para mudança e como os casos de uso são orquestração das regras de negócio usar outros casos de uso dificultaria muito a manunteção. Seria isto, casos de uso não podem usar outros casos de uso.
Começa 14:00
começa no começo longe do fim
Galo cantando à meia noite é um Galo Dev...😂😂
Um dica para os testes q eu particularmente achei melhor, em vez de instanciar a class a cada teste, instanciei apenas uma vez de forma global antes de todos os testes, dessa forma:
const routeProps = {
title: 'minha rota',
startPosition: {lat: 0, lng: 1},
endPosition: {lat: 0, lng: 1},
points: []
}
let globalRoute = new Route(routeProps) // só usar o "globalRoute" dentro dos testes em vez de escrever tudo isso de novo a cada teste
Oi Wilhams, gostei da ideia, usar Clean Code na programação ajuda na legibilidade do código!
@@argentinaluiz :)
Great point!!!! 2:30:30 -- Conteudo sobre Clean Architecture eh muito importante pra nivel Semi-senior e Senior.
Valeuuu mesmo pelo conteudo!!
Parabéns Luiz! Simplesmente SHOW!
Opa valeu Celso!
Caro. Estou assistindo essa ex-live depois de um ano, mas vou tentar tirar minha dúvida. São 2. A primeira é onde entraria no seu exemplo a camada que tem os controladores? Segunda dúvida. Se eu quero buscar dados de relações entre entidades, por exemplo uma query com Join, na implementação do meu repository pra qual entidade eu eu faria essa implementação?
Show de aula, Luiz. Obrigado!!!!
No caso, de forma resumida: a cada de entidades ficam as regras de negócios. Já as camadas de casos de usos ficam os serviços que gerenciam essas regras de negócios, semelhantes a camada controller do MVC. A camada Core é responsável pela persistência dos dados e a última camada é para o framework, seja web, deskop, mobile etc. Está correta, professor, essa visão do modelo?
Sensacional! Parabéns e obrigada!
Oi Carolina, muito obrigado pelo feedback!! ;)
Quais os proximos videos continuando o tema de Clean arch e Nest ou outros FW?
No 2:50:55 você deu um exempl de findById, como eu faria para ele retornar sempre uma promise Rota quando implementado no repositório, já que nem sempre vai existir o elemento com o ID ?
É sobre o boom e a roadmap pra ser um Senior de respeito, ou seja do pedreiro pro arquiteto
Extremamente útil, obrigado!
exatamente, agora quala entidade do youtube
Saindo um pouco do assunto, você tá utilizando WSL e eu atualmente estou utilizando tudo pelo Windows mesmo, qual seria a vantagem de utilizar o WSL?
show de bola, qual o plugin de theme utilizado ?
Oi Paulo, tudo bem?
Para o VSCode uso o Github Theme no modo dark.
Para o terminal, uso o oh-my-zsh e powerlevel10k
Em relação ao design, colocar cada Service/UseCase dentro de uma só classe (RouteService por exemplo) seria uma abordagem ruim?
Oi Vinicius, tudo bem?
Eu respondi esta pergunta neste minuto do vídeo: ua-cam.com/video/yLPxkIxbNDg/v-deo.html
Existe alguma recomendação em usar OOP na criação de entidades envez de programação funcional? Se fosse aplicar Clean Archecture no React, acho confuso criar coisas usando OOP quando todo React usa functional programing.
Oi F4ilcon, tudo bem? Autores como Robert Martin, Vernon e Eric Evans relatam que a orientação a objetos é o que melhor se adequa a este tipo de arquitetura, mas não sendo impossível aplicar os conceitos em outros paradigma. Em linguagens funcionais a recomendação para modelar as entidades é usar as estrutura que modelam dados, já em React.js a Clean Arch não pode ser aplicada 100%, porque o objetivo do front-end não é o mesmo do back-end, além de que necessitamos que o front-end fique "preso" ao React para funcionar, mas conseguimos usar conceitos de separação de responsabilidades e SOLID para evitar que regras de negócio não fiquem embutidas dentro dos componentes.
@@argentinaluiz Perfeito a sua colocacao, acho que cai no conto de applicar clean arch em tudo(front-end), agora pesquisando vejo que nao se consegue applicar 100%, apenas o SOLID e mesmo com alguma restricao, parabens pelo conteudo, seu material eh de longe o mais esclarecedor que encontrei sobre o assunto, direto no assunto usando um exemplo bem simples.
Sobre o repository lidar com entidades, tive a mesma dúvida que o pessoal pq o uncle Bob diz (tanto no livro como no artigo do blog dele) que somente estruturas de dados simples (incluindo DTOs) podem cruzar camadas, nunca Entidades (sim, ele diz explicitamente isto). Se isto fere o conceito de repository, vale dizer que o uncle Bob no livro não cita o termo repository z e sim fala em "Gateway de banco de dados" (e interface do mesmo) de forma genérica.
What data crosses the boundaries.
Typically the data that crosses the boundaries is simple data structures. You can use basic structs or simple Data Transfer objects if you like. Or the data can simply be arguments in function calls. Or you can pack it into a hashmap, or construct it into an object. The important thing is that isolated, simple, data structures are passed across the boundaries. We don’t want to cheat and pass Entities or Database rows.
Oi Felipe, tudo bem?
Obrigado pelo feedback!
No livro Clean Architecture, o Robert Martin menciona "Gateway" em vez de "Repository", porque um Gateway pode fazer outras coisas além de I/O, ele pode se comunicar com um sistema externo também, então seria um conceito mais abstrato. Tem algumas pessoas que realmente preferem usar Gateway no nome mesmo sendo um repositório puro na essência.
Sobre a questão do que passar para o repositório/gateway quando queremos salvar, remover, criar deve ser uma entidade, porque o objetivo é lidar das entidades. O trecho que você expôs diz respeito na comunicação entre as camadas, que seriam controllers vs use cases, consumers vs use cases, cli vs use cases. Estas são camadas que estão acessados a camada de aplicação. Os repositórios são um contrato interno da camada de aplicação.
Entendeu a ideia?
@@argentinaluiz entendi sim, valeu!
@@argentinaluiz Então o repository/gateway faz parte da camada de useCases ?? porque se não a interação com a camada de entities seria incorreto
@@FabrizioSilveira-l1y Olá Fabrizio, tudo bem?
Sim, eles fazem parte da camada de aplicação, como dos use cases
Aula incrivel, mas fiquei como uma duvida.
Como seria o CRUD com o Clean Architecture ?
uai, cada caso de uso ali que ele fez é uma parte do crud(Create = create-route.use-case, Read = list-all-routes.use-case), seria só implementar as operações de atualizar e deletar como use-cases
Cada o link da continuação usando next
Aula sensacional!
sensacional é vc essa aula é épica
Professor uma dúvida, foi criado uma interface chamada RouterRepositoryInterface onde nesta interface se tem os métodos de salvar e listar todas as rotas, bom estaria errado se eu criasse uma interface pra cada um dos métodos onde se facilitaria nos testes unitarios .
Olá Paulo, tudo bem?
Poderíamos ter algum assim:
class RouteRepositoryInterface extends InsertActionInterface, ListAllActionInterface{
}
Seria uma forma de permitir que repositórios pudessem implementar somente o que necessitasse, mas isto isto mais feito para aplicações mais complexas.
Paulo posso responder a essa questão usando o principio da segregação de interfaces (ISP), caso sua interface for usado por uma classe concreta, e não implemente todos os seus métodos, você estaria ferindo o ISP! No caso não é errado criar uma interface para cada método, porém como disse, se não estiver ferindo o príncipio não vejo problema em utilizar penas uma interface para as duas ações! Abraços.
Eu posso ter um caso de uso se comunicando com outro na camada de application?
Olá, parabéns pelas aulas, aprendendo muito... só queria saber pq vc colocou RoutProps assim:
const routeProps: RouteProps = {
title: 'minha rota',
startPosition: {lat: 0, lng: 1},
endPosition: {lat: 0, lng: 1}
}
Fiz dessa forma e a rota passou do mesmo jeito no test:
const routeProps = {
title: 'minha rota',
startPosition: {lat: 0, lng: 1},
endPosition: {lat: 0, lng: 1}
}
Seria alguma peculiaridade da doc?
Olá Wilhams, tudo bem? Muito obrigado pelo feedback! Isto funciona, porque é do mesmo tipo que RouteProps. O TypeScript analisa os tipos verificando os tipos das propriedades, se baterem está correto!
@@argentinaluiz entendi, Obrigado!
Luiz.. eu nem trabalho mais com programação, fui apenas junior por 6 meses em actionscript(do antigo flash), sou profissional da infra, mas resolvi fazer a semana toda completa, e não entendi ainda porque tente cria um private set title e depois um update title... qual a diferença? se quer setar o titulo porque não apenas mudar o set do title para public? Ele não é um método???? e se vc faz um update tiltle qual a intenção de manter o set title como private?
ah, acho que entendi quando vc chegou no updatePoints.. a ideia é apenas validar a regra de negócio?
Oi Volt, tudo bem?
Este é uma ideia pra enriquecer a modelagem de dados. Quando usamos os setters para definir os dados eles ficariam espalhados, soltos pela aplicação sem deixar claro as intenções das regras de negócio, o que chamados de modelo anêmico, sem expressividade.
O updateTitle faz sentido considerando que iremos querer atualizar o título da rota sem mexer no resto, mas isto somente se fizer sentido pro negócio, entendeu a ideia?
@@argentinaluiz Entendi sim, obrigado pela resposta... explicitar a questão do negócio, muito legal essa visão, parece que sempre deveria ter sido assim...
Eu poderia colocar dentro do folder application os meus controllers ?
Olá Paulo, tudo bem?
Não, a pasta controllers faz da parte infraestrutura, segunda a arquitetura hexagonal ela é um adaptador de entrada para os use cases.
Olá, pq vc usa it em alguns testes e test em outros, procurei saber a diferença e vi que eles são "iguais"
It é um alias para teste, são iguais, mas fica mais descriminativo usar it
describe(Resource) - it(should do something)
Leia se
descrever(Recurso) - isso(deve fazer alguma coisa)
Trabalho e estudo... não consigo acompanhar aulas on-line... vocês estão disponibilizando esses vídeos gravados?
Oi César, tudo bem?
As lives continuarão no canal!
;)
Por que ainda usa classes ?
Oi Lucas, tudo bem?
Usamos classes, porque desde a ES6 é um padrão nativo do JavaScript e elas ajudam a montar a orientação a objetos.
Aula toooooooop
Fala ai galera, tenho um dúvida. É normal uma use-case se comunicar com outras use-cases? Ou estariamos a violar a Arquitetura Limpa?
Oi Henrique, tudo bem? Obrigado pelo feedback!
Sim, estamos violando a Clean Arch se um caso de uso utilizar outro, porque os casos de uso obedecem ao Single Responsability Principle, ou seja, a classe tem ter apenas um motivo para mudança e como os casos de uso são orquestração das regras de negócio usar outros casos de uso dificultaria muito a manunteção.
Seria isto, casos de uso não podem usar outros casos de uso.
Top top
alguem ai te o link do discord? nao estou econtrando
Oi Gabriel, tudo bem? Acesse a página da imersão na descrição que tem o link do discord lá.
Só faltou o push 🙂? codeedu/live-imersao-fullcycle8-typescript-clean-arch
Olá Yuri, tudo bem? O código-fonte já está disponível!