Cara, teu canal é muito bom! Cai aqui de paraquedas e estou aprendendo muito. Estou em um momento onde quero transitar de Jr para Pleno, sou desenvolvedor Java e já apliquei alguns insights que você mostrou em códigos que produzi. Parabéns pelo conteúdo!
Como sempre conteúdo muito bom, 10:25 vejo que é muito importante a gente não criar muitas abstrações "camadas" desnecessárias e criar realmente as que precisa e sem ter o sentimento de culpa. isso vem com o passar do tempo e da troca de experiencia com outras pessoas/livros/vídeos.
Tu pegou realmente o espírito da coisa hahah, é exatamente isso que tu disse!! A cada nova abstração a gente faz, isso acaba trazendo um pouco mais de complexidade, tem gente que gosta de purismo no código e não abre mão, eu já prefiro entender as necessidades e ver se realmente vale a pena a gente abrir mão de simplicidade em troca de mais um nível de abstração.
Fala,@@josemaria2094tô organizando tudo pra abrir essa semana a área de membros. Acabou atrasando pq o estúdio tava em obra, fica ligado que muito provavelmente até o fim de semana vai estar disponível! Tmj, abração!
@@brunomptube fala Bruno!! Então cara, o problema dessa abordagem é que nossa entidade não pode ter a responsabilidade de se auto processar pois isso envolve diversos passos de muito baixo nível, exemplo.. pra processar um pedido a gente vai ter que bater no gateway de pagamentos e só o fato disso acontecer acaba acoplando nossa entidade a comunicações externas. Pensa no padrão repository por exemplo, a responsabilidade de salvar um pedido no banco não é do próprio pedido e sim de um repositório que recebe um pedido e realiza a inserção no banco sacou?
Primeiramente, excelente conteúdo, não sou de ficar dando like e nem comentando nos vídeos, mas tenho feito isso em todos os seus, a qualidade do material e sua didática são excelentes. Agora a minha dúvida... Você sempre fala, por exemplo, para não representar as propriedade da classe com primitivos e sim com objetos. Mas, se eu precisar criar uma classe chamada Produto e nele eu preciso ter o nome e a descrição, não deveria criar uma classe com um primitivo nome: "Produto A" e descrição: "Minha descrição"? Assim poderia injetar na classe Order. Estou confuso quanto a este conceito
Cara primeiramente valeu demais pelo feedback!! Tmj mesmo!! Quanto a tua dúvida vamos lá... Não tem problema algum tu utilizar tipo primitivo pra representar o nome do produto ou algumas propriedades que não tenham comportamento porém a utilização de objetos sempre vai te auxiliar do ponto de vista das regras de negócio. Imagina que temos 2 cenários, no cenário 1 tu tem uma classe de Produto e um produto tem um nome, tá tudo bem que esse nome seja representado como String porém no cenário 2, imagina que nessa tua mesma classe de Produto tu vai ter que fazer uma alteração no código e agora o produto só pode ter um nome com até 20 caracteres, se isso acontecer tu muito provavelmente vai ter que criar um método dentro da classe de produto pra ficar validando se tem 20 caracteres o valor que tu jogou dentro da Produto na hora de instanciar, agora tu imagina que um produto tem 10 propriedades e cada uma precisa ser validada de acordo com suas respectivas regras de negócio ex: Nome, Peso, Altura do produto etc... Tu vai acabar entupindo a classe de Produto com vários métodos de verificação dos atributos delas e isso vai acabar arrebentando tua classe com um monte de método e um monte de motivo pra mudar. O pulo do gato tá no seguinte, se o nome do teu produto for um objeto, tu coloca dentro desse objeto a validação dos 20 caracteres e se por ventura não for respeitado, ele lança uma exception daí cada propriedade do produto cuida da sua respectiva regra de negócio, mas daí cabe a analise se tu perceber que não tem regra de negócio vinculada a determinada propriedade pode utilizar tipo primitivo sem problema. Rapaz... foi o maior comentário que já escrevi até hoje hauhuehaueh
@@RenatoAugustoTech excelente explicação, muito obrigado por responder! Eu sempre imagino estes cenários no Ruby on rails, pois é a stack que trabalho, e ainda me surgem várias dúvidas sobre como usar das boas práticas aliadas a esse cenário. Não sei se você já teve alguma experiência com ele, mas hoje os models são totalmente acoplados com o banco de dados, então grande parte dos atributos são em primitivos. Existem outros casos onde eu estendo o MVC aos services, e esses sim, são classes simples, mais ainda fico pensando em como transformar uma classe que só tenha um primitivo para poder passar à uma classe maior para opera-lo. Imagino que isso iria granulizar demais ou virar over engineer. A propósito, não vi nenhum contato no seu perfil, se puder, me envie via inbox para podermos trocar mais ideias. Valeu!
@@ticoh9832 Então, o Ruby On Rails ele utiliza o padrão Active Record que é o mesmo padrão utilizado pelo Laravel quando falamos de persistência no banco de dados, então basicamente uma Model representa uma tabela e fica muito dificil da gente conseguir tratar nossas models como entidades, eu sei bem o que tu ta passando pq eu sofri bastante com isso quando usava Laravel. O padrão oposto ao Active Record é o Data Mapper e esse sim é muito bom pq ele é completamente orientado a objetos e daí nós temos nossas Entidades e temos os Repositories que fazem o trabalho de persistência das nossas entidades e com isso a gente ganha muita flexibilidade. Até existem algumas soluções pra o Active Record mas acaba que me incomoda muito ter que fazer muito esforço então no final faz mais sentido utilizar forçado mesmo. E quanto a rede me chama lá no Linkedln que a gente troca uma ideia boa, por hora eu to sem insta pra focar 100% no canal mas em breve eu reativo e até domingo vou criar uma comunidade pra galera mais engajada também
Excelente explicação e ótima didática como sempre, parabéns Renatão!
Que beleza de conteúdo ! Dá gosto de assistir !
Giovani, obrigado demais pelo reconhecimento irmão!! Tmj
Cara, teu canal é muito bom! Cai aqui de paraquedas e estou aprendendo muito. Estou em um momento onde quero transitar de Jr para Pleno, sou desenvolvedor Java e já apliquei alguns insights que você mostrou em códigos que produzi. Parabéns pelo conteúdo!
Valeu demais@@mourafaell, fico feliz que tenha curtido o conteúdo! Conta cmg nessa jornada aí hein!!
@RenatoAugustoTech Opa, pode deixar! Eu quem agradeço e ainda faço questão de compartilhar!
Muito bom Renato
@@rafaelvasconcelos2206 valeu Rafa tmj!!
Como sempre conteúdo muito bom, 10:25 vejo que é muito importante a gente não criar muitas abstrações "camadas" desnecessárias e criar realmente as que precisa e sem ter o sentimento de culpa. isso vem com o passar do tempo e da troca de experiencia com outras pessoas/livros/vídeos.
Tu pegou realmente o espírito da coisa hahah, é exatamente isso que tu disse!! A cada nova abstração a gente faz, isso acaba trazendo um pouco mais de complexidade, tem gente que gosta de purismo no código e não abre mão, eu já prefiro entender as necessidades e ver se realmente vale a pena a gente abrir mão de simplicidade em troca de mais um nível de abstração.
Thanks!
Hahah valeu demais pela força Gui! Tmj!!!!
Maratonei a playlist e to gostando muito do conteudo, ainda mais da forma que você passa, objetivo e claro
Hahahah valeu demais!! E fica ligado que vem mais conteúdos por aí!! Abração!
Canal diferenciado, com conceitos extremamente importantes apresentados de maneira clara e acessível.
Esse tipo de comentário que motiva a trazer ainda mais qualidade nos vídeos, valeu mesmo@@elvesbrito9633 !! Abração
Ótimo vídeo!
Obrigadooooo
Fala Renato, beleza?
Obrigado pela contribuição.
Não tem área de membros/patreon ainda ?
Abraço
Fala,@@josemaria2094tô organizando tudo pra abrir essa semana a área de membros. Acabou atrasando pq o estúdio tava em obra, fica ligado que muito provavelmente até o fim de semana vai estar disponível! Tmj, abração!
Ótimo video, Renato. O que você acha da própria entidade Order ter a façade para processar o pedido? Do contrário a entidade Order não fica anêmica?
@@brunomptube fala Bruno!! Então cara, o problema dessa abordagem é que nossa entidade não pode ter a responsabilidade de se auto processar pois isso envolve diversos passos de muito baixo nível, exemplo.. pra processar um pedido a gente vai ter que bater no gateway de pagamentos e só o fato disso acontecer acaba acoplando nossa entidade a comunicações externas. Pensa no padrão repository por exemplo, a responsabilidade de salvar um pedido no banco não é do próprio pedido e sim de um repositório que recebe um pedido e realiza a inserção no banco sacou?
No caso do php, oque voce costumar usar no tipo primitivo para valores monetários?
Conteúdo Excelente meu irmão, parabéns
Então Anthony, no caso do PHP tem essa lib aqui que faz esse trabalho com valores monetários, dá uma olhada lá no packagist depois - moneyphp/money
@@RenatoAugustoTech fechou, gratidão irmão
Primeiramente, excelente conteúdo, não sou de ficar dando like e nem comentando nos vídeos, mas tenho feito isso em todos os seus, a qualidade do material e sua didática são excelentes. Agora a minha dúvida... Você sempre fala, por exemplo, para não representar as propriedade da classe com primitivos e sim com objetos. Mas, se eu precisar criar uma classe chamada Produto e nele eu preciso ter o nome e a descrição, não deveria criar uma classe com um primitivo nome: "Produto A" e descrição: "Minha descrição"? Assim poderia injetar na classe Order. Estou confuso quanto a este conceito
Cara primeiramente valeu demais pelo feedback!! Tmj mesmo!! Quanto a tua dúvida vamos lá... Não tem problema algum tu utilizar tipo primitivo pra representar o nome do produto ou algumas propriedades que não tenham comportamento porém a utilização de objetos sempre vai te auxiliar do ponto de vista das regras de negócio. Imagina que temos 2 cenários, no cenário 1 tu tem uma classe de Produto e um produto tem um nome, tá tudo bem que esse nome seja representado como String porém no cenário 2, imagina que nessa tua mesma classe de Produto tu vai ter que fazer uma alteração no código e agora o produto só pode ter um nome com até 20 caracteres, se isso acontecer tu muito provavelmente vai ter que criar um método dentro da classe de produto pra ficar validando se tem 20 caracteres o valor que tu jogou dentro da Produto na hora de instanciar, agora tu imagina que um produto tem 10 propriedades e cada uma precisa ser validada de acordo com suas respectivas regras de negócio ex: Nome, Peso, Altura do produto etc... Tu vai acabar entupindo a classe de Produto com vários métodos de verificação dos atributos delas e isso vai acabar arrebentando tua classe com um monte de método e um monte de motivo pra mudar. O pulo do gato tá no seguinte, se o nome do teu produto for um objeto, tu coloca dentro desse objeto a validação dos 20 caracteres e se por ventura não for respeitado, ele lança uma exception daí cada propriedade do produto cuida da sua respectiva regra de negócio, mas daí cabe a analise se tu perceber que não tem regra de negócio vinculada a determinada propriedade pode utilizar tipo primitivo sem problema.
Rapaz... foi o maior comentário que já escrevi até hoje hauhuehaueh
@@RenatoAugustoTech excelente explicação, muito obrigado por responder!
Eu sempre imagino estes cenários no Ruby on rails, pois é a stack que trabalho, e ainda me surgem várias dúvidas sobre como usar das boas práticas aliadas a esse cenário. Não sei se você já teve alguma experiência com ele, mas hoje os models são totalmente acoplados com o banco de dados, então grande parte dos atributos são em primitivos. Existem outros casos onde eu estendo o MVC aos services, e esses sim, são classes simples, mais ainda fico pensando em como transformar uma classe que só tenha um primitivo para poder passar à uma classe maior para opera-lo. Imagino que isso iria granulizar demais ou virar over engineer.
A propósito, não vi nenhum contato no seu perfil, se puder, me envie via inbox para podermos trocar mais ideias. Valeu!
@@ticoh9832 Então, o Ruby On Rails ele utiliza o padrão Active Record que é o mesmo padrão utilizado pelo Laravel quando falamos de persistência no banco de dados, então basicamente uma Model representa uma tabela e fica muito dificil da gente conseguir tratar nossas models como entidades, eu sei bem o que tu ta passando pq eu sofri bastante com isso quando usava Laravel. O padrão oposto ao Active Record é o Data Mapper e esse sim é muito bom pq ele é completamente orientado a objetos e daí nós temos nossas Entidades e temos os Repositories que fazem o trabalho de persistência das nossas entidades e com isso a gente ganha muita flexibilidade. Até existem algumas soluções pra o Active Record mas acaba que me incomoda muito ter que fazer muito esforço então no final faz mais sentido utilizar forçado mesmo. E quanto a rede me chama lá no Linkedln que a gente troca uma ideia boa, por hora eu to sem insta pra focar 100% no canal mas em breve eu reativo e até domingo vou criar uma comunidade pra galera mais engajada
também
Boa!
👍