É a primeira vez que eu vejo alguém explicar DDD com cenários realmente de mercado, que abordam complexidades que temos no dia-a-dia, e não aqueles exemplos do faz de conta, cheio de firula de quem realmente não entende o que se passa no ambiente produtivo. Esse material tá sendo muito útil pra mim e para meu time Elemar, muito obrigado!
Elemar é um absurdo, é um poço de conhecimento com uma didática invejável. Precisou de 25 minutos pra explicar com maestria um tema que parece ser simples, mas na real é bem complexo...
Achei extremamente teórico, me senti na aula da filosofia, aonde parece que se está aprendendo muito, mas não se gravou nada, um rapaz de grande conhecimento porém que aulas que não acho que auxiliam no desenvolvimento, mas obviamente vou votar positivo, pois não é um leigo falando, se nota muito conhecimento.
Depende muito do nosso momento. Se vc não sentiu a dor de projetar um sistema e perceber que virou ou está virando uma big ball of mud, então não é tão útil estudar DDD, eu por exemplo comecei a estudar DDD porque achava que precisava aprender melhor os patterns do DDD como repostory, entity, etc. Mas hoje vejo que o mais importante é entender muito bem a parte mais estratégica: subdomínio, contextos delimitados e mapas de contexto.
Excelente conteúdo. Descobri seu canal hoje ouvindo um podcast que você gravou alguns anos sobre DDD. Estou lendo o livro vermelho e soube da sua playlist, vim aqui para reforçar meu conhecimento. Muito obrigado por compartilhar
Pelo que entendi nao existe um "gabarito" para determinar o tamanho dos bounded contexts, tudo depende do dominio. Mas seria aceitável que os bounded contexts fossem os deptos de uma compania?
O que não ficou tão claro pra mim, foi a questão do código. É feita chamadas direta, por exemplo, no bounded context de Loja On-line ao Centro de distribuição, no caso, rolaria uma importação direta do arquivo de entidade do contexto delimitado do centro de distribuição? Ou apenas uma chamada a uma função Facade ?
excelente video. Assunto mais complexo do ddd na minha opiniao. Cuidado na associação de sharedkernel com sdk. E um ponto que poderia ser mais explorado é justamente a otica do negocio em termos de core domain e generic subdomain , pois o generic pode ser consumido de outra empresa, onde la seja tratado esse elemento como core domain ou vc pode desenvolver um interno paliativo onde ele seja o core domain na visao do negocio como uma solução desacoplada.
@@EximiaCo Saudações Elemar! Já se passaram uns 2 anos mas vou postar aqui algo relacionado ao que o Paulo Pizarro levantou, pois é minha dúvida também, e estou há 2 dias correndo atrás de algum exemplo relacionado à essa questão. Estou estudando DDD e a analisar o Espaço Problema e Espaço Solução para um comércio de gases industriais. Nesse tipo de negócio, é vendido o gás em cilindros que são ativos da empresa em uma transação de troca de cilindros com o cliente (como no comércio de botijões de gás de cozinha), como também existe locação de ativos (cilindros) e algumas dessas empresas também fazem serviços de manutenção em cilindros de clientes. Sendo assim, temos 3 fontes de receita para a empresa: venda de gás, locação e serviços de manutenção em cilindros. As 3 atividades são suportadas por um bom conjunto de processos de controle de estoque e logística (subdomínios de suporte). Partindo princípio que o core domain de uma empresa é onde está sendo produzido o valor que a mesma entrega para os clientes, e onde ela obtém o lucro, e estas 3 atividades elegíveis a bounded contexts estão relacionadas a este aspecto do domínio global do negócio, podemos afirmar que esses 3 bounded contexts podem formar o core domain? Um core domain pode ter mais de 1 bounded context? Ou será que precisamos eleger um desses bounded contexts pra ser o supra core domain (venda de gás) e os outros serem apartados dessa modelagem (locação e serviços), e cada um desses apartados estabelecer seu próprio Espaço Problema e Solução onde serão core domain, e consumir os outros subdomínios de suporte que o supra core domain se relaciona, como subdomínios genéricos? Nesse caso estaríamos estabelecendo uma relação de parceria entre esses 3 Espaço Solução? Meio doido tudo isso né 😆
Acredito que não @Elton, a ideia do ACL é você não acoplar o seu domínio com uma implementação que dependa de fatores externos, você dentro do seu código separar através de contratos(interfaces) a implementação de serviços externos com o seu domínio. já o shared Kernel são elementos que podem trazer duplicação de códigos em bounded context diferentes(ou serviços diferentes)
O Fornecedor (upstream) fornece uma interface estável para o Cliente (downstream) consumir. No exemplo dado, o Centro de distribuição pode fornecer informações de Estoque e de Entrega, e os contextos delimitados de Loja Física e Online podem consumir. Por conta dessa relação de dependência, é importante que o upstream ofereça uma interface estável e que se comunique com os downstream, para repassar as suas atualizações afim de manter o consumo correto dos dados. Se o upstream não tiver grande (ou mesmo se tiver nenhuma) influência no downstream, se configura uma relação de Conformista. No exemplo dado, o contexto de Cobrança (downstream) é conformista ao de Serviço de Cobrança do BB (upstream), pois ele tem que se adequar a quaisquer alteração e não tem influência grande nele.
É a primeira vez que eu vejo alguém explicar DDD com cenários realmente de mercado, que abordam complexidades que temos no dia-a-dia, e não aqueles exemplos do faz de conta, cheio de firula de quem realmente não entende o que se passa no ambiente produtivo. Esse material tá sendo muito útil pra mim e para meu time Elemar, muito obrigado!
Elemar é um absurdo, é um poço de conhecimento com uma didática invejável.
Precisou de 25 minutos pra explicar com maestria um tema que parece ser simples, mas na real é bem complexo...
Vídeo absurdamente bom. Pela primeira vez uma explicação do DDD de forma não chata, que seja capaz de manter o foco no assunto. Excelente didática.
Top 👊 parabéns pelo conteúdo
Achei extremamente teórico, me senti na aula da filosofia, aonde parece que se está aprendendo muito, mas não se gravou nada, um rapaz de grande conhecimento porém que aulas que não acho que auxiliam no desenvolvimento, mas obviamente vou votar positivo, pois não é um leigo falando, se nota muito conhecimento.
Depende muito do nosso momento. Se vc não sentiu a dor de projetar um sistema e perceber que virou ou está virando uma big ball of mud, então não é tão útil estudar DDD, eu por exemplo comecei a estudar DDD porque achava que precisava aprender melhor os patterns do DDD como repostory, entity, etc. Mas hoje vejo que o mais importante é entender muito bem a parte mais estratégica: subdomínio, contextos delimitados e mapas de contexto.
Elemar, parabéns pelo excelente conteúdo e mto obrigado por compartilhar conhecimento e experiência!
Excelente conteúdo Elemar! Parabéns e obrigado por compartilhar.
Parabéns e obrigado pelo ótimo material.
Muito completo! Show!
Excelente conteúdo. Descobri seu canal hoje ouvindo um podcast que você gravou alguns anos sobre DDD.
Estou lendo o livro vermelho e soube da sua playlist, vim aqui para reforçar meu conhecimento. Muito obrigado por compartilhar
Muito bom. Já na espera dos próximos vídeos
Excelente conteúdo novamente! Obrigado por compartilhar seu conhecimento e experiência!
Muito didático, parabéns e obrigado, muita coisa ficou clara depois desse vídeo!
Excelente, parabéns
Em uma arquitetura distribuída por exemplo, esses bounded context seriam os microservicos?
Pelo que entendi nao existe um "gabarito" para determinar o tamanho dos bounded contexts, tudo depende do dominio.
Mas seria aceitável que os bounded contexts fossem os deptos de uma compania?
Show.
Adiciona na descrição o link das outras partes
Parabéns pelo ótimo conteúdo.
O que não ficou tão claro pra mim, foi a questão do código. É feita chamadas direta, por exemplo, no bounded context de Loja On-line ao Centro de distribuição, no caso, rolaria uma importação direta do arquivo de entidade do contexto delimitado do centro de distribuição? Ou apenas uma chamada a uma função Facade ?
Vivo essa cenário descrito aí...loja física, on-line , CD e fábrica.... e é muito complexo.
excelente video. Assunto mais complexo do ddd na minha opiniao. Cuidado na associação de sharedkernel com sdk. E um ponto que poderia ser mais explorado é justamente a otica do negocio em termos de core domain e generic subdomain , pois o generic pode ser consumido de outra empresa, onde la seja tratado esse elemento como core domain ou vc pode desenvolver um interno paliativo onde ele seja o core domain na visao do negocio como uma solução desacoplada.
Como tratar se no espaço do problema existirem dois ou mais core domain?
Dê um exemplo.
@@EximiaCo Saudações Elemar! Já se passaram uns 2 anos mas vou postar aqui algo relacionado ao que o Paulo Pizarro levantou, pois é minha dúvida também, e estou há 2 dias correndo atrás de algum exemplo relacionado à essa questão.
Estou estudando DDD e a analisar o Espaço Problema e Espaço Solução para um comércio de gases industriais. Nesse tipo de negócio, é vendido o gás em cilindros que são ativos da empresa em uma transação de troca de cilindros com o cliente (como no comércio de botijões de gás de cozinha), como também existe locação de ativos (cilindros) e algumas dessas empresas também fazem serviços de manutenção em cilindros de clientes. Sendo assim, temos 3 fontes de receita para a empresa: venda de gás, locação e serviços de manutenção em cilindros. As 3 atividades são suportadas por um bom conjunto de processos de controle de estoque e logística (subdomínios de suporte).
Partindo princípio que o core domain de uma empresa é onde está sendo produzido o valor que a mesma entrega para os clientes, e onde ela obtém o lucro, e estas 3 atividades elegíveis a bounded contexts estão relacionadas a este aspecto do domínio global do negócio, podemos afirmar que esses 3 bounded contexts podem formar o core domain? Um core domain pode ter mais de 1 bounded context? Ou será que precisamos eleger um desses bounded contexts pra ser o supra core domain (venda de gás) e os outros serem apartados dessa modelagem (locação e serviços), e cada um desses apartados estabelecer seu próprio Espaço Problema e Solução onde serão core domain, e consumir os outros subdomínios de suporte que o supra core domain se relaciona, como subdomínios genéricos? Nesse caso estaríamos estabelecendo uma relação de parceria entre esses 3 Espaço Solução? Meio doido tudo isso né 😆
Nesse exemplo (loja online e loja física) seria aplicável a ACL entre os bounded contexts, ao invez do shared kernel?
Acredito que não @Elton, a ideia do ACL é você não acoplar o seu domínio com uma implementação que dependa de fatores externos, você dentro do seu código separar através de contratos(interfaces) a implementação de serviços externos com o seu domínio. já o shared Kernel são elementos que podem trazer duplicação de códigos em bounded context diferentes(ou serviços diferentes)
Gostei muito do vídeo. Dúvida.. nao entendi muito bem a parte upstream e downstream. Poderia explicar? :)
O Fornecedor (upstream) fornece uma interface estável para o Cliente (downstream) consumir. No exemplo dado, o Centro de distribuição pode fornecer informações de Estoque e de Entrega, e os contextos delimitados de Loja Física e Online podem consumir. Por conta dessa relação de dependência, é importante que o upstream ofereça uma interface estável e que se comunique com os downstream, para repassar as suas atualizações afim de manter o consumo correto dos dados.
Se o upstream não tiver grande (ou mesmo se tiver nenhuma) influência no downstream, se configura uma relação de Conformista. No exemplo dado, o contexto de Cobrança (downstream) é conformista ao de Serviço de Cobrança do BB (upstream), pois ele tem que se adequar a quaisquer alteração e não tem influência grande nele.