Muito bom vídeo, ótimos exemplos do que é e não é DDD. O que poderíamos também definir como o "Coração do Software" seriam as rotinas em que a empresa ganha dinheiro e/ou economiza dinheiro. Afinal de contas, negócios vivem dessas duas coisas =)
Muito interessante sua explicação. Atualmente estou lendo o Domain Driven Design e assistir esse vídeo foi importante pra ter uma noção do que esperar do livro. Agora vou estudar. Obrigado 🙏
Muito bom o vídeo! A "aplicação" das coisas que estão no hype sem o mínimo de reflexão deixa todo mundo vulnerável a esse tipo de confusão. Isso leva diretamente a código legado que precisa de um especialista Tenho estudado Model-Driven software engineering (MDSE) atualmente e percebo como isso já foi um hype bem grande alguns anos atrás e a única coisa que "sobrou" do hype foi o "ódio" ao UML. Se o DDD seguir o mesmo caminho, só vai sobrar um futuro de desenvolvedores falando mal de alguma dessas arquiteturas comuns (Onion Architecture, etc....) como se isso fosse DDD.
Ótimo Vinícius. Estou estudando microserviço e acredito que essa arquitetura seja uma das melhores formas de implementar e representar o DDD. Muito bom.
Muito bom o video. Ainda tô terminando o livro, mas isso que vc aponta sobre não ter uma forma definida de aplicar DDD é o que confunde muita gente mesmo, ao meu entender. Fiquei até surpreso ao ler o livro e ver que o Evans é muito mais "nuanced" do que o evangelistas que vejo online. Uma coisa que achei interessante tbm e, ao meu ver, vale lembrar, é que a ideia de "linguagem onipresente" e "modelo profundo" são muito mais complexas do que aparentam. Em determinado ponto do livro ele fala sobre como eles chegaram em uma abstração que era menos óbvia para leigos no domínio. O domínio era um aplicativo de transporte de cargas em que a modelagem inicial envolvia as classes navio e container. Ele conta que, depois de terem trabalhado meses com especialistas na área, eles chegaram a um modelo que não tinha as classes navio e container. Eles chegaram em um nível abstração/sofisticação diferente. Os navios ainda estavam lá, mas foram abstraídos para "viagem de embarque", enquanto os "containers" praticamente desapareceram do modelo (embora fossem representados como tal em um outro aplicativo). Ele até fala que sempre que um novo programador auditava o código, as primeiras sugestões eram sempre "faltam as classes navio e container". Ele até fala que não é que eles não fossem inteligentes, eles só não participaram do processo de descoberta. Enfim, tô gostando bastante da leitura e recomendo pra todos. Só não fiquem chatos achando que tem uma única forma de por em pratica, como alguns evangelistas. Como falei, é bem mais "nuanced" do que esperava.
Perfeito, Tony. O que acontece pra galera ficar mais "quadrada" é justamente esse ruído na informação. Muita gente aprende sobre DDD apenas em artigos rápidos e não confere a fonte, o que acaba gerando esse conhecimento bem incompleto.
Obrigado por esclarecer, eu estou estudando DDD, com TDD e estava achando quase estranho eu utilizar várias estratégias diferentes na minha aplicação como MVVM, Strategy, Factory e varais outrar, estava quase ficando confuso até que você chegou. Entendi que DDD não é arquitetura, é uma filosofia, e minha arquitetura é MVVM e o resto são estratégias e patterns, obrigado. Agora meu conceito fechou, dahora. Simplificou bem, não simplificou de mais ao ponto de citar exemplos com animais e não complicou de mais falando de mais coisas abstratas como CQRS, dahora ganhou um inscrito.
Minha dificuldade é justamente porque muitos "vendem" a ideia de ser um arquitetura, ai cada exemplo ou curso que faço tem uma estrutura/arquitetura diferente.
Uma das minhas dificuldade é a interpretação de responsabilidade para com cada parte do código. Se eu coloco meus output DTO na camara da adaptadores ou se faz sentido ter viewmodel na cadama de application para entregar aquele pedaço de dados ao cliente
Línguagem Ubíqua é você trazer a linguagem utilizada no negócio que representa elementos dele para formar esses elementos importantes para o negócio dentro do Software? o_O
NÃO TEM IDEIA de quantas entrevistas estou fazendo, onde LIDERES TECNICOS estão me perguntando sobre ""ARQUITETURA DDD"" e o que eu acho dele dessa ""ARQUITETURA""!?!!.... JÁ PERDI UM PENCA DE VAGAS (DEVIDO O EGO) CORRIGINGO ESSA GALERA
Olha, dá pra corrigir sem perder a vaga. Se falar com jeitinho e mostrar fontes (principalmente trechos do livro do Eric Evans), dá até pra sair por cima na situação. :-D
Que bom que curte o conteúdo, Rodrigo. Essa música no final eu nunca nem ouço. A galera da edição que coloca. Se estiver incomodando muito posso ver com eles pra trocar ou tirar, mas acho que isso é bem secundário, né!? kkkkk
@@DiasDeDev Claro, Vinícius... é só pra comentar mesmo! rsrsrs Isso realmente não importa. O conteúdo é ótimo, ainda mais para mim que to conseguindo caminhar bastante no php mesmo tendo pouco tempo diário para estudar...
A filosofia, sim. Mas uma arquitetura em camadas, provavelmente não. A filosofia é basicamente se comunicar de forma clara com o domínio. Se existe uma equipe não técnica, não tem motivos pra dificultar a comunicação. Mas as ferramentas não necessariamente precisam ser todas utilizadas. ;-)
Não é só isso, mas isso é um dos pontos, sim. DDD te dá ferramentas pra tornar seu domínio mais compreensível. A linguagem onipresente é uma. Há mapas de contexto, identificação de domínio principal, de suporte e sub-domínios, etc
Fala, Guilherme. Aqui tem alguns interessantes: - amzn.to/3rwsK7u - amzn.to/3GxVOQp - amzn.to/3uxAwAa - amzn.to/3Hzs9HT - amzn.to/3LgEIu0 - amzn.to/3Gx01Uw O último é o livro "original" de DDD. Os 2 anteriores são versões mais "simples" de se ler sobre o mesmo assunto. Aqui tem um específico sobre DDD em PHP: - amzn.to/3J7kBwn
@@DiasDeDev Minha Nossa Senhora do Perpétuo Socorro!! Esses livros sobre DDD custa 1 ano de inscrição na Alura ou mais! O conteúdo dentro disso aí deve valer ouro.
Cada dia inventam umas 10 siglas novas, tu vai ver uma vaga tem uma tripa de siglas, tem que fazer um curso para saber oque estao pedindo... e muitas vezes a metade é frescura ou é uma coisa simples que complicam e inventam uma sigla...
@@DiasDeDev Sim, vi que voce falou que surgiu de um livro e tal, me refiro no geral, todo dia estão inventando siglas novas, frameworks, linguagens, padrões, etc.... tem vagas de emprego que é assustador de ver a quantidade de coisas que pedem... algumas eu acho que nao estão procurando um desenvolvedor, estão procurando o mestre dos magos...
Esse fundo rosado frio não favoreceu seu tom de pele, sugiro que vc procure um colorista para fazer uma análise de colorimetria, nada a ver com o vídeo não, só um toque mesmo. O vídeo ta excelente 👍🏼
