DDD (Domain-Driven Design) // Dicionário do Programador

76.62k views1846 WordsCopy TextShare
Código Fonte TV
🤝 𝗛𝗢𝗦𝗧𝗚𝗔𝗧𝗢𝗥 → https://codigofonte.click/HGGE6asEjTFv8 Vamos falar sobre Domain-Driven Desi...
Video Transcript:
e contextualizando o ddd ou também driven design que traduzido é o design guiado pelo domingo uma abordagem para a modelagem software que centraliza o desenvolvimento na criação de um modelo de domínio ou seja a criação da modelagem de software baseada em implementar modelos que refletem as competências da organização a complexidade do negócio dessa abordagem que muitas vezes é confundida com uma tecnologia como se fosse um freimor ou como uma arquitetura mas nesse dicionário do programador pretendemos retirar todas as suas dúvidas sobre de de de de a porta df é um prazer ter você aqui novamente
conosco já sabe que vamos te pedir para curtir esse vídeo né se essa é sua primeira vez aqui no canal eu sou gabriel e essa aqui é a minha esposa vanessa somos um casal bem louco de programadores e jalecos que todas as semanas está aqui destrinchando um termo ou uma tecnologia especialmente para você já se inscreve e ativa o sininho para não perder as próximas notificações nesse episódio estamos falando de de até poderia ser diz que a gente ele até a distância mas o nosso ddd é um domingo e vem designer que surgiu através de
um livro também vivem design atacando as complexidades no coração do software lançado em 2003 por eric evans para tudo antes de continuar vamos esclarecer um ponto bem básico mais importante quando falamos aqui de design não estamos nos referindo ao visual nem nada relacionado a layout da aplicação o design do ddd referente ao projeto dedera oferece ferramentas de modelagem estratégica e tática para entregar um software de ar e com o objetivo de acelerado desenvolvimento de aplicações que lidam com processo de negócio de complexo ela não é uma tecnologia ou uma metodologia pode ser utilizado independente da
linguagem não importa se fechar ou java o ddd também não é arquitetura em camadas e não impõem processos rígidos ao time em seus princípios o ddd é sobre discussão escuta a incompreensão todo um esforço para centralizar o conhecimento transformando ele em modelos de domínio e em softwares queiram de verdade atender às necessidades e expectativas dos usuários próprio eric ewans cita duas frases bem importantes sobre esse princípio os programadores não estão interessados no domínio eles aprendem apenas o que aplicação deve fazer e não os princípios por trás dela só ser útil pode até ser desenvolvido dessa
maneira mas o projeto nunca chegar a um ponto onde novas funcionalidades poderosas surgiram como desdobramento de funcionalidades existentes profundo e verdadeiro mas talvez você ainda e tenha compreendido tão a fundo essa frase pois ainda temos que explicar alguns dos conceitos por trás o domínio vivem design como o próprio domínio de milho me fez lembrar da hospedagem de sites embora esse não seja o sentido que estamos aguardando hoje por aqui né mas vamos aproveitar para deixar um agradecimento especial a nossa parceira host gator que nos ajuda de velas a trazer cada vez mais conteúdo de qualidade
para você a host gator é aquela parceira para toda hora com uma equipe de suporte sempre pronta para te ajudar nossa nem que te dá um desconto e serviços da hostgator está aqui embaixo na descrição voltando ao domingo o domínio é um negócio da sua empresa ou o assunto do seu projeto existe ainda o cordel mente que é a principal parte de um domínio é que deixa bem claro sua preocupação no entendimento do negócio e diz que entenderam o negócio é o único meio de implementado de de um projeto nessa implementação existem basicamente dois papéis
o time de desenvolvimento que somos nós mesmos e o e esses são os especialistas no negócio por exemplo se estamos criando uma aplicação para auxiliar um escritório de advocacia e os advogados que seriam os nossos domain expert eles seriam capazes de guiar a equipe para desenvolver um bom sócia tirando dúvidas definido regras processos e termos sendo assim o desenvolvimento com ddd a uma jornada de descoberta todos aprendem os deves com os do homem é fértil e os domingos perto estão os deves falando o intermos esses são dos pilares do de desse especialistas da área e
desenvolvedores devem trabalhar em conjunto é preciso que ambos falem a mesma língua surge então a linguagem o bico utilizada por toda a equipe do projeto desenvolvedores pensamos em classes método dos componentes quais objetos criar qual relacionamento entre eles pensamos em herança polimorfismo e por aí vai os do meio expert não entendi nadica de nada disso eles são especialistas um negócio conhecem e sabem como a empresa deve funcionar tô aqui por sua vez também é um bando de termos que nós não fazemos ideia do que se trata porém isso a linguagem o beco é uma linguagem
daequipe compartilhada e principalmente entendido por todos durante o projeto ela também vai evoluir o outro pilar é o bauner contax a delimitação do contexto ela é o limite conceitual uma vez que todo domingo é colocado em um modelo ela pode se tornar complexo demais e o bauer conta exatamente onde ela irá delimitar nesses contextos baseados nas intenções de negócio cada balde ele consegue se poderá ter a sua linguagem no bico a sua abordagem de arquitetura de armazenamento de dados e até sua própria equipe de desenvolvimento esse é um exemplo de como os contextos de vendas
e suporte se dividir dá para ver que consumidor e produto aparecem duas vezes mas embalde conta diferente isso significa que eles possuem papéis e responsabilidade diferente dentro de cada contexto o produto no contexto de suporte pode ser uma entidade com a pé e já em vendas vamos precisar de mais informações como valores toque por exemplo estou em cada contexto produto possui características diferentes e provavelmente comportamentos também diferentes para criar esse modelo entender como os bons ele conta que se relacionam e como eles se comunicam é utilizado o contexto map o modelo que vai nos dar
a visão geral do software existem alguns padrões de relacionamento entre os baldes contax e eles implicam diretamente na estratégia de como os times do projeto irão trabalhar na dependência entre eles na arquitetura e até na estratégia de comunicação os principais tipos de relacionamentos entre contextos são shared canon quando vários baldes e conta que se compartilham de um mesmo domínio alterar ele significa que todas as equipes serão afetadas próximas com o valimento quando existe um relacionamento cliente-fornecedor chamado no ddd de downstream upstream significa que a equipe upstream pode ter êxito e interdependente da equipe downswing ou
seja um com esse é o fornecedor do serviço e o outro é o consumidor tecnicamente as equipes irão definir teste de aceitação automatizados queiram validar as interfaces que a equipe antes fim fornece com isso a equipe de fornecedores poderá fazer as modificações sem se preocupar em quebrar o sistema conforme nesse relacionamento o balde conta downstream está conformado que o modelo upstream não atende suas necessidades e o pior que as modificações realizadas por eles irão impactar diretamente em seu contexto ele aceita o fato e se vira com que tem ficando aí a tempo a todas as
mudanças realizadas porta mesmo só aqueles bauru e conta que são parceiros pelo menos dá para saber né estão unidos por uma dependência mútua e deverão trabalhar em conjunto mas corrupção leia nesse relacionamento a equipe downstream de ser de criar uma camada para proteger o seu contexto das notificações do upstream é muito comum de ser encontrado em sistema de legal se vê um modelo simples não de com 3 metros o terceiro deu para perceber que o desenho em si é bem simples mesmo um quadro branco e uma caneta já são suficientes para a criação desse modelo
ele podemos ver os contextos da aplicação de gestão financeira usuários web o serviço de banco online e o de rastreamento de despesa e as relações entre eles por exemplo entre a aplicação de gestão financeiro downstream e o serviço do banco online opções existe uma camada de anticorrupção já entre o contexto da aplicação de gestão financeira e o contexto de rastreamento de despesas existe uma relação de parceria com outros dois termos bem utilizados quando falamos de dormem seven designs são design estratégico e o design touch com design estratégico ou modelagem estratégica é tudo que já falamos
na verdade é bem difícil imaginar a implementação do ddd sem aplicar os conceitos da modelagem estratégia vão ver não outro grande autor do assunto disse que o design estratégico é como fazer um rascunho antes de entrar nos detalhes da implementação ele destaca o que é eu acabei de importante o negócio que como dividir o trabalho por importância e como fazer integrações da melhor maneira já onde saem tacou a modelagem tática diz respeito à implementação e usa o do meio model pa ter uma uma abordagem que diz como escrever as classes que irão mapear os modelos
do mundo real e implementar os comportamentos do negócio existem também alguns padrões na modelagem tática como por exemplo entes e o velo e objetos que define os conceitos do domínio o domínio service que assumir responsabilidades que não se encaixam em outro projeto que define fronteiras entre objetos e o factory repositories que lida com a criação e armazenamento de objetos é claro que criar um modelo para um sistema complexo não é uma tarefa fácil é comum vermos modelos onde os limites são inconsistentes e que geram os conhecidos códigos macarrônico se aquele sistema que ninguém quer por
isso é importante não criarmos uma big ball of mudd ou grande bola de lama que é impossível trocar e para isso não acontecer evite modelos abrangente são únicos e cuidado com modelos com conceitos e nomes que tenham significado global até porque será quase impossível estabelecer um acordo entre os diferentes do meio esperto poderíamos nos deliciar por mais algumas horas de vídeo se fossemos explicar tudo que envolve o ddd nossa dica para você que quer ir mais a fundo nesse assunto é ler um livro do eric e ele vai trazer um conjunto de práticas ideais do
design técnicas baseadas em experiências princípios fundamentais e exemplos do de de aplicado em projetos da vida real é um daqueles livros que exigem dedicação para leitura mais que vale a pena no final vamos deixar também nossa vencimento especial ao bruno brito que nos ajudou a criar esse conteúdo com seu artigo sobre domingo e vem design o link do artigo está aqui na descrição nós vamos ficando por aqui conta pra gente o que achou e deixa uma sugestão de tema para o próximo dicionário do programador e até a próxima para você não que saudade da gente
que tal dá uma olhadinha nesse outro vídeo aqui sobre te dê uma excelente sugestão test-driven development na verdade bem até o ddd é verdade vamos falta falar de bebê de rose é o ddd de pdd mimi trava-língua danada viu mas vai lá assistir tv
Related Videos
SOLID (O básico para você programar melhor) // Dicionário do Programador
16:22
SOLID (O básico para você programar melhor...
Código Fonte TV
169,705 views
Domain-Driven Design: The Last Explanation You'll Ever Need
21:05
Domain-Driven Design: The Last Explanation...
Software Developer Diaries
11,961 views
LINGUAGENS DE PROGRAMAÇÃO QUE SÃO TENDÊNCIAS EM 2025
20:35
LINGUAGENS DE PROGRAMAÇÃO QUE SÃO TENDÊNCI...
Código Fonte TV
40,123 views
Domain Driven Design: What You Need To Know
8:42
Domain Driven Design: What You Need To Know
Alex Hyett
143,208 views
Scrum // Dicionário do Programador
17:19
Scrum // Dicionário do Programador
Código Fonte TV
167,064 views
Clean Architecture + DDD: Você pensa que sabe. Só que não!
22:10
Clean Architecture + DDD: Você pensa que s...
Full Cycle
14,436 views
DDoS (O ataque de segurança mais comum, mas que dá para prevenir) // Dicionário do Programador
12:15
DDoS (O ataque de segurança mais comum, ma...
Código Fonte TV
21,916 views
Microservices // Dicionário do Programador
9:51
Microservices // Dicionário do Programador
Código Fonte TV
80,984 views
What is DDD - Eric Evans - DDD Europe 2019
57:06
What is DDD - Eric Evans - DDD Europe 2019
Domain-Driven Design Europe
265,950 views
The absolute beginner's guide to Domain Driven Design with Symfony | Neal Brooks | sfday 2020
55:33
The absolute beginner's guide to Domain Dr...
GrUSP
11,101 views
API // Dicionário do Programador
11:59
API // Dicionário do Programador
Código Fonte TV
300,632 views
Aprenda DDD (Domain Driven Design) do jeito certo
59:58
Aprenda DDD (Domain Driven Design) do jeit...
Full Cycle
108,351 views
SOLID fica FÁCIL com Essas Ilustrações
19:46
SOLID fica FÁCIL com Essas Ilustrações
Filipe Deschamps
342,248 views
Domain Layer Structure & Skeleton | Clean Architecture & DDD From Scratch Tutorial | Part 13
16:10
Domain Layer Structure & Skeleton | Clean ...
Amichai Mantinband
128,109 views
Accelerating Event-driven Architecture with Domain-driven Design • Brian Zambrano • GOTO 2023
46:56
Accelerating Event-driven Architecture wit...
GOTO Conferences
5,473 views
DEVS COM 35+ ESTÃO SEM ESPAÇO NO MERCADO DE TRABALHO?
16:44
DEVS COM 35+ ESTÃO SEM ESPAÇO NO MERCADO D...
Código Fonte TV
42,489 views
Clean Code // Dicionário do Programador
14:22
Clean Code // Dicionário do Programador
Código Fonte TV
169,064 views
DDD Explained in 9 MINUTES | What is Domain Driven Design?
9:44
DDD Explained in 9 MINUTES | What is Domai...
Marco Lenzo
44,485 views
DDD, SOLID, Clean Code, Clean Architecture... Isto é para você?
1:15:43
DDD, SOLID, Clean Code, Clean Architecture...
balta.io
25,775 views
6 SEGREDOS DO GITHUB COPILOT NO VS CODE
16:50
6 SEGREDOS DO GITHUB COPILOT NO VS CODE
Código Fonte TV
5,609 views
Copyright © 2024. Made with ♥ in London by YTScribe.com