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
