Agregados | DDD do jeito certo | Parte 06

[@carloswanderley8868]

O Elemar sempre termina os seus vídeos agradecendo-nos por assistirmos até o final. Amigo - permita-me chamá-lo assim - nós é que agradecemos muito por seus conteúdos maravilhosos. É um prazer pra mim assistir seus vídeos até o último segundo! Que didática! Que forma tranquila de transmitir temas complexos de forma tão simples e de fácil percepção. Em todas as suas explicações eu consigo, mentalmente, visualizar o seu diálogo associando-o aos meus projetos e de imediato percebo os conceitos e onde estou errado. E é muito bom quando percebo que não estou fazendo do jeito certo, por que logo após as suas aulas eu já parto para a correção imediata! Então só tenho a agradecer por seus conteúdos! Tenho buscado assistir a todos os seus conteúdos! Seu site já está nos destaques do meu navegador Edge para fácil acesso e também já assinei o seu podcast via Deezer! Em qualquer mídia, são materiais de excepcional qualidade técnica. Mais uma vez, parabéns e muito obrigado! 👍👍👍

[@rcosta551]

DDD deveria ser uma obrigação pois a engenharia não resolve tretas de negócio.

[@euthomas]

Um conteúdo desse de graça e em português, é sério isso?

[@EximiaCo]

É sim! :)

[@joaodacruz333-b7d]

Analisar a partir da característica da mutabilidade/imutabilidade para definir se é uma entidade ou um objeto de valor faz todo sentido e elucida muito bem a questão. Muito obrigado.

[@sergio201083]

Muito Top Elemar!

[@JeanCesar]

Muito obrigado Elemar. Aprendendo muito com essa série. Aproveitei para me aprofundar mais e já comprei o livro vermelho do DDD.

[@andersonszdc3211]

agora sim em kkkk, os exemplso ficaram tops!

[@eversoncoutinhooficial]

Eu é quem agradeço. Cheguei até o final até o momento.

[@yurimelo3404]

Mostra implementações de como persistir agregados.

[@joaocardoso7643]

Tô pesquisando muito sobre DDD esses últimos dias. Esse vídeo é de longe o mais didático que eu vi no KZbin. Parabéns e muito obrigado!

[@rcosta551]

kzbin.info/door/3PGn-hQdbtRiqxZK9XBGqQ

[@lemol]

Espetacular!

[@LucasGomesSantiago]

Cara, que conteúdo valioso! Muito obrigado Mestre Elemar!

[@erickod]

Sua abordagem e didática é muito clara. Muito bom!

[@joaopaulorodriguessantos3687]

Explicação clara e genial, Elemar! Muito obrigado por compartilhar um material de tamanha qualidade conosco. Dá vontade de te ouvir falar por horas. Abraço!

[@rcosta551]

Elemar parabéns pela didática.

[@MariaDeFatima5bc]

Conteúdo incrível, estava tentando entender esse conceito a alguns dias e vi seu video e entendi de cara, grata pelo conteúdo!

[@longuinni]

Excelente!!!

[@nacasadobeirinha1524]

para ser breve, parabéns, compartilhado!

[@ddnasc]

Que série incrível... Obrigado por compartilhar seus conhecimentos.

[@robinsonrenato]

Show mesmo. É bom conhecermos pessoas assim, que imagino ter muita coisa na vida, imagino que seus dias são cheios, mas que mesmo assim tem um tempo pra se dedicar a nós, meros mortais. Valeu

[@jcresgate]

Ótimo video e parabéns pela iniciativa. Estou compartilhando bastante, porque sei da qualidade do conteúdo

[@wallacersgarbim]

Muito boa explicação, parabéns

[@carlosjunior5371]

Excelente como sempre. Código, para um bom projetista, é um mero detalhe. Obrigado

[@alessandrodesouza]

Pensando em microsserviços, se eu tivesse um para tratar de 'clientes' e outro pra tratar dos 'pedidos', eu deveria usar um entidade simplificada (apenas com dados pertinentes) de 'cliente' no serviço de 'pedidos' para evitar que pedido faça chamadas síncronas aos serviço de 'clientes'?

[@kelvinsand]

Acredito que se você estiver separando os seus microserviços por contextos delimitados você poderia sim ter essa entidade de cliente no serviço de pedido.

[@lucasalmeidapaula2721]

tenho a mesma dúvida

[@paulosantana8056]

Acredito que não somente cliente, mas tbm estoque e produto.

[@ClevertonHeusner]

Excelente aula.

[@fabioboris]

Obrigado pelo excelente conteúdo. O assunto de agregados me fez lembrar do livro NoSQL Distilled (Sadalage & Fowler). Parabéns pelos vídeos! Estão cada vez melhores.

[@sdph2007]

Obrigado pela aula, com certeza foi muito esclarecedora.

[@andersonzup]

Como sempre, colocando na nossa cabeça aquilo que ninguém mais consegue, muito obrigado.

[@luan_maik]

Esta aula complementou muito bem a aula anterior

[@brunohenrigarcia9966]

Muito obrigado pelo conhecimento compartilhado!

[@_jullliao]

Elemar, em cima do exemplo que você deu entre Cliente x Pedido: Em casos que as informações de endereço sejam persistida na entidade Cliente, como ficaria a organização?

[@nonatowebby4166]

Eleomar, que Deus continue te abençoando e guiando para nos dar esse excelente conteúdo, cara, muito bom. Queria tirar uma dúvida, sobre a questão das APIs. Se fossemos implementar, por exemplo, um Endpoint que altera a quantidade de itens na lista, qual você acha mais adequada: /api/orders/1/order_items/4/increase_quantity ou fazer algo que representa mais uma agregação, como: /api/orders/1/increase_order_item (passando os dados do OrderItem como payload) ?? grato

[@rockerhistory]

E se o cliente tem um saldo , e uma carteira e a integridade transacional do pedido requer a atualização dessa carteira, como representar?

[@jhenriquecosta]

Usando a abordagem de component do nhibernate o objeto de valor N precisa de um id

[@fernando.r.rinaldi]

Uma dúvida: pq a relação de order -> address não é considerada uma relação de referência igual a de customer? Address também não é considerado uma existência independente?

[@miguelczar]

Muito bom, bem claro, mas tenho uma dúvida que sempre me perseguiu. Quando eu vou listar os pedidos do cliente, é ideal já trazer os itens de cada pedido e o endereço? Pois em uma tela que possui a lista de pedidos, eu só traria os itens de pedido após eu selecionar um pedido, diminuindo o tempo da busca. Qual a melhor forma de organizar isso?

[@leandrotrindade3381]

Fala Miguel, tudo certo ? Estou começando a aplicar conceitos de DDD em projetos e estou com a mesma dúvida nesse momento. Conseguiu alguma resposta sobre essa questão ?

[@ricardomozartlino2264]

Fiquei com uma dúvida, na classe Order ele terá o Customer ou um customerId? a propósito, @Elemarjr, excelente aula! Parabéns pela didática.

[@filipecotrimmelo7714]

Pelo o que eu entendi assistindo até aqui apenas, teria apenas customerId. Porque ele falou que não teria uma propriedade de navegação, mas isso foi o que eu entendi.

[@diogokrejci8029]

Primeiramente, parabéns pelo excelente vídeo. Porém eu tenho uma dúvida. Como devo representar o cadastro de dados nesse modelo. Por exemplo: caso eu precise cadastrar um novo Endereço, Novos itens de serviço. Como esses conceitos entraram na minha base de dados? Precisarei criar um outro domínio para fazer essa carga de dados?

[@LeonardodeJesusMiron]

Fiquei com essa dúvida também. Na minha ignorante e antiga experiência em modelagem de dados, um cliente possui N endereços e os pedidos possuem uma "cópia" do endereço ou um relacionamento com a "versão" de um endereço de um cliente. Assim um cliente pode possuir N endereços e não necessariamente utilizar eles em pedidos.

[@Rob-uz4wi]

Só uma coisa a dizer: Muito obrigado. Como posso pagar por isso ? Bem, desde já digo q a Exímia e o Elemar estao em minhas orações.

[@carlosl8832]

👍🏽

[@roqlee]

Muito bom!