Gostei muito do vídeo, Otávio. Uma pergunta: se o caso de uso tivesse que retornar um lote, você retornaria um objeto do domínio ou um DTO também? No caso de ser um DTO, você usaria o mesmo criado para o repositório (BatchData) ou criaria outro?
Só os casos de uso e as entidades podem manipular entidades. Assim, eu retornaria o DTO. Com sistemas pequenos como esse e o usado no livro acho que não há problema em ter um DTO somente. A ideia de ter várias estruturas de dados seria para você só entregar os dados necessários (por exemplo, um ViewModel só com os dados necessários para aquela view). Mas quando o sistema é pequeno e simples não vejo necessidade de ficar criando várias dessas estruturas de dados. Parece-me que complica mais do que ajuda.
Bom dia, ótimos conteúdos! Veio-me uma dúvida, eu estou cada vez mais aplicando clean architecture nos meus projetos em nestjs. Apesar, do mesmo ser um framework com princípios de SOLID, cada vez mais estou desacoplando algumas libs ou serviços que utilizo. Nessa semana, dando continuidade nesse processo de aplicar o clean architecture no meu boilerplate, eu me deparei com uma situação que me causou um grande dilema. Eu utilizo o class-validator que tem uma ótima integração com nestjs, normalmente para higienizar o dto e fazer algumas validações (de tipo, regex, etc.) antes de entrar no controller. Para melhorar minha produtividade, com passar do tempo fui criando decorators auxiliares. Um desses decorators é um que verifica se o usuário existe pelo id, e-mail, por exemplo. O é ótimo para o usuário que consegue tem uma resposta de todos os erros ou inconsistência no seu to. Entretanto, devido a isso, eu preciso desta validação no meu caso de uso. Que de certo modo, estou criando um acoplamento do meu caso de uso com o decorator do class-validator. Pensado somente em clean architecture isto é errado, mas para o usuário ter esse comportamento é ótimo. Eu lembro que você disse em um de seus vídeos que os padrões não são feitos para ser seguido a risca, como exemplo o SOLID, que não precisa ser aplicado todos os princípios em todos os projetos. Por mais que o class-validator é bem mantida, quando saber se vale a pena deixar seu código acoplado, ou não existe essa possibilidade? Gostaria de saber um ponto de vista diferente. Obrigado desde já, e desculpe pelo texto enorme.
Se você quiser desacoplar, acho que não é difícil: crie uma interface para o validador e faça um adapter que chama o teu validador específico. Você perde a conveniência da anotação mas é uma saída.
@@otaviolemos muito do meu dilema é, lendo artigos e o livro (não terminei ainda). Sempre é expresso que o caso de uso, deve conter o regra de negócio. Mas se eu a colocar parte dela no dto com auxio do class-validator, eu estaria fugindo desse princípio? Tenho impressão que estou acoplando a regra de negócio a minha maneira de implementar usando class-validator com decorators.
excelente vídeo, é interessante porque na arquitetura limpa o uncle bob define os casos de uso de uma forma particular "são as regras de negócio do sistema", eu considero como uma definição para a arquitetura limpa, fora dela a definição é aquela padrão que aprendemos na faculdade e nos diagrama de UML "todas as funcionalidades que o usuário pode fazer no sistema"
Olá Otavio, tudo bem? Em um caso de geração de um ID ou Hash de uma senha, quem deve estar gerando esses conjuntos de caracteres é a entidade ou use case?!
@@otaviolemoscara, já ao meu ver é a entidade, posso ter por exemplo o método getHashPassword() ou por exemplo na entidade User, posso ter no construtor um id recebido ou gerado naquele momento, posso ter tb o método getUnicId()
Otávio outra pessoa uma dúvida para modelar as entities podemos usar as annotations por exemplo do java na entidade criada ? tipos isso "sujaria " a entidade ?
Vc ta confundindo DDD entity com model. Os models (classes anotadas com jpa) sao a representacao fisica de um registro do banco de dados. Pensando em arquitetura hexagonal, os models ficam na camada de adapters e as entitities ficam na domain, dentro do hexagono, assim voce tem que fazer o mapper sempre que houver a interacao com o banco
Muito bom! Use Cases seria algo similar à camada Application do livro azul do DDD do Evans? Eu sempre entendi essa parte como um maestro ou orquestrador onde também tem acesso a objetos de cross-cutting.
Excelente vídeo. Estava lendo sobre isso essa semana no livro do Khalil Stemmler.
O Khalil é fera!
Gostei muito do vídeo, Otávio. Uma pergunta: se o caso de uso tivesse que retornar um lote, você retornaria um objeto do domínio ou um DTO também? No caso de ser um DTO, você usaria o mesmo criado para o repositório (BatchData) ou criaria outro?
Só os casos de uso e as entidades podem manipular entidades. Assim, eu retornaria o DTO. Com sistemas pequenos como esse e o usado no livro acho que não há problema em ter um DTO somente. A ideia de ter várias estruturas de dados seria para você só entregar os dados necessários (por exemplo, um ViewModel só com os dados necessários para aquela view). Mas quando o sistema é pequeno e simples não vejo necessidade de ficar criando várias dessas estruturas de dados. Parece-me que complica mais do que ajuda.
@@otaviolemos entendi. Mais uma vez, obrigado pelo vídeo e pelas respostas.
@@otaviolemoscara, pois eu manipulo entidades dentro de repositório tb
Otavio, seu conteúdo é ESPETACULAR, mas sobe o som por favor!
Bom dia, ótimos conteúdos! Veio-me uma dúvida, eu estou cada vez mais aplicando clean architecture nos meus projetos em nestjs. Apesar, do mesmo ser um framework com princípios de SOLID, cada vez mais estou desacoplando algumas libs ou serviços que utilizo. Nessa semana, dando continuidade nesse processo de aplicar o clean architecture no meu boilerplate, eu me deparei com uma situação que me causou um grande dilema. Eu utilizo o class-validator que tem uma ótima integração com nestjs, normalmente para higienizar o dto e fazer algumas validações (de tipo, regex, etc.) antes de entrar no controller. Para melhorar minha produtividade, com passar do tempo fui criando decorators auxiliares. Um desses decorators é um que verifica se o usuário existe pelo id, e-mail, por exemplo. O é ótimo para o usuário que consegue tem uma resposta de todos os erros ou inconsistência no seu to. Entretanto, devido a isso, eu preciso desta validação no meu caso de uso. Que de certo modo, estou criando um acoplamento do meu caso de uso com o decorator do class-validator. Pensado somente em clean architecture isto é errado, mas para o usuário ter esse comportamento é ótimo. Eu lembro que você disse em um de seus vídeos que os padrões não são feitos para ser seguido a risca, como exemplo o SOLID, que não precisa ser aplicado todos os princípios em todos os projetos. Por mais que o class-validator é bem mantida, quando saber se vale a pena deixar seu código acoplado, ou não existe essa possibilidade? Gostaria de saber um ponto de vista diferente. Obrigado desde já, e desculpe pelo texto enorme.
Se você quiser desacoplar, acho que não é difícil: crie uma interface para o validador e faça um adapter que chama o teu validador específico. Você perde a conveniência da anotação mas é uma saída.
@@otaviolemos muito do meu dilema é, lendo artigos e o livro (não terminei ainda). Sempre é expresso que o caso de uso, deve conter o regra de negócio. Mas se eu a colocar parte dela no dto com auxio do class-validator, eu estaria fugindo desse princípio? Tenho impressão que estou acoplando a regra de negócio a minha maneira de implementar usando class-validator com decorators.
excelente vídeo, é interessante porque na arquitetura limpa o uncle bob define os casos de uso de uma forma particular "são as regras de negócio do sistema", eu considero como uma definição para a arquitetura limpa, fora dela a definição é aquela padrão que aprendemos na faculdade e nos diagrama de UML "todas as funcionalidades que o usuário pode fazer no sistema"
Olá Otavio, tudo bem? Em um caso de geração de um ID ou Hash de uma senha, quem deve estar gerando esses conjuntos de caracteres é a entidade ou use case?!
Fala Janderson, beleza? Eu acho que encaixa melhor nos casos de uso.
@@otaviolemoscara, já ao meu ver é a entidade, posso ter por exemplo o método getHashPassword() ou por exemplo na entidade User, posso ter no construtor um id recebido ou gerado naquele momento, posso ter tb o método getUnicId()
Otávio outra pessoa uma dúvida para modelar as entities podemos usar as annotations por exemplo do java na entidade criada ? tipos isso "sujaria " a entidade ?
Sujaria sim. Você cria uma dependência de uma camada mais externa na camada mais interna. Pode fazer? Pode. Mas aí já não é Arquitetura Limpa.
@@otaviolemos brigado pela repostas vish é que fazer isso vai gerar mais complexidade ainda se tratando de spring :D valeu !
Vc ta confundindo DDD entity com model. Os models (classes anotadas com jpa) sao a representacao fisica de um registro do banco de dados. Pensando em arquitetura hexagonal, os models ficam na camada de adapters e as entitities ficam na domain, dentro do hexagono, assim voce tem que fazer o mapper sempre que houver a interacao com o banco
Muito bom!
Use Cases seria algo similar à camada Application do livro azul do DDD do Evans? Eu sempre entendi essa parte como um maestro ou orquestrador onde também tem acesso a objetos de cross-cutting.
O áudio poderia ser mais alto.