Olá Elemar, tem algum vídeo onde você fala sobre Ids fortemente tipados ? Eu já vi algumas pessoas falando sobre mas eram gringos e eles não mostraram nos videos como fizeram as abstrações como a raiz de agregação, mas o que dá para ver é que eles usam classe um interface de abstração para a entidade filha Entidade onde T1 seria o Id da entidade como você mostrou no video e T2 a chave primária do Agregado por exemplo, mas se houver por exemplo Entidades que tenham mais de um relacionamento, eu teria que criar uma outra abstração que aceite por exemplo 3 ids ?
Muito bom Elemar, obrigado pelo conteudo. Você esta contribuindo muito, e tenho certeza que ajudou muita gente. Estou inicianto um projeto, e a todo momento vejo um equivoco em nossa modelagem e implementação. Agora só preciso mudar o entendimento da equipe sobre DDD. haha
professor me corriga se eu estiver muito errado, rsrs, pelo que pesquisei depois de ver a aula, a entidade ela nao "representa" a minha tabela do banco de dados, mas sim o dominio do meu sistema, esta certo o que eu acabdei de falar ?
Acredito que a resposta seja: O custo da consulta é muito elevado. A medida que o sistema cresce, vai gerar gargalos. Custo de armazenamento é mais barato que o de processamento. Sendo assim, uma "view materializada" com os dados já prontos deve ser mais vantajosa.
Eu entendi toda a parte conceitual, o que nao entendo eh o seguinte, endereco sendo um Value Object significa que ele nao tem um ID, porem o endereco tem que vir de algum lugar, e geralmente ele eh salvo no banco de dados. Como que fica nesse caso?
O pulo do gato tá aí. Para persistir no banco precisa de um id sim, mas ele pode e deve ser invisível pro domínio. Vc teria um modelo pro domínio e seria mapeado pra outro modelo no banco.
Uma das melhores explicações sobre value objects que já vi em Português.
Muito obrigado!
@@elemarjr Eu que agradeço
Olá Elemar, tem algum vídeo onde você fala sobre Ids fortemente tipados ? Eu já vi algumas pessoas falando sobre mas eram gringos e eles não mostraram nos videos como fizeram as abstrações como a raiz de agregação, mas o que dá para ver é que eles usam classe um interface de abstração para a entidade filha Entidade onde T1 seria o Id da entidade como você mostrou no video e T2 a chave primária do Agregado por exemplo, mas se houver por exemplo Entidades que tenham mais de um relacionamento, eu teria que criar uma outra abstração que aceite por exemplo 3 ids ?
Meus parabéns pela didática, a aula foi espetacular
Muito bom Elemar, obrigado pelo conteudo. Você esta contribuindo muito, e tenho certeza que ajudou muita gente. Estou inicianto um projeto, e a todo momento vejo um equivoco em nossa modelagem e implementação. Agora só preciso mudar o entendimento da equipe sobre DDD. haha
Muito obrigado a turma toda!!
Deu para tirar bastante conhecimento
professor me corriga se eu estiver muito errado, rsrs, pelo que pesquisei depois de ver a aula, a entidade ela nao "representa" a minha tabela do banco de dados, mas sim o dominio do meu sistema, esta certo o que eu acabdei de falar ?
Ótima aula! :)
Por qual motivo ao realizar um "join" em um banco relacional você acaba "matando um panda"?
Acredito que a resposta seja: O custo da consulta é muito elevado. A medida que o sistema cresce, vai gerar gargalos. Custo de armazenamento é mais barato que o de processamento. Sendo assim, uma "view materializada" com os dados já prontos deve ser mais vantajosa.
Pelo custo envolvido.
Eu entendi toda a parte conceitual, o que nao entendo eh o seguinte, endereco sendo um Value Object significa que ele nao tem um ID, porem o endereco tem que vir de algum lugar, e geralmente ele eh salvo no banco de dados. Como que fica nesse caso?
O pulo do gato tá aí. Para persistir no banco precisa de um id sim, mas ele pode e deve ser invisível pro domínio. Vc teria um modelo pro domínio e seria mapeado pra outro modelo no banco.