Esse vídeo é perfeito para quem nunca entendeu DDD, sempre achou algo abstrato demais, e nunca conseguiu implementar na prática. Parabéns pelas explicações!
Excelente conteúdo! Acabei de começar a trabalhar como Dev e o sênior pediu que eu estudasse sobre DDD e clean code antes de começar a codificar. Fora aprender React e Node (eu venho do Java kkk).
Cara, que vídeo sensacional, explica tudo muito bem de maneira progressiva do inicio ao fim. Por mais que falem que se mais usa em apps grandes, da perfeitamente pra usar os mesmos princípios em modelagens de programas bem mais simples, ajudando assim a documentar melhor o fluxo.
Caraio mano. Nunca vi uma didática tão perfeita sobre um tema que pra mim parecia absurdo. O pessoal enfeita demais tornando tudo romantizado e você conseguiu tornar prática essa teoria e trazer mais pra realidade. Muito bom mano. Parabéns!
Super Concreto Will, a partir daí surgem algumas duvidas e estou pensando em como aplicar isso aqui em Portugal para os sistemas do governo para agregar valor, tanto no negocio quanto no desenvolvimento. Mas como aqui quase 100% dos projetos são monolitos, vou tentar abstrair para iniciar algo com DDD. Valeu a aula Will.... vc é o kara!
Weslley, que conteúdo! Quem já conhecia mas não havia consolidado o entendimento, agora conseguiu consolidar. Parabéns pela apresentação e clareza na transmissão do conhecimento. Eu gostaria de saber como aplicar a segunda parte, onde teríamos os microsserviços e se possível sob uma arquitetura Hexagonal ( ports and adapters).
Esse video é sensacional, acredito que deveria ser legendado em inglês para aumentar seu alcance. Eu com certeza indicaria para amigos aqui (moro fora do país)
Finalmente!! Finalmente entendi esse tal de DDD, que não significa Discagem Direta à Distância (os mais antigos devem se lembrar dos "orelhões" azuis rsrsrs)
Formei em 98 em Ciência da Computação com ênfase em análise de sistemas, minha carreira foi focada em Redes, especialização, mestrado e doutorado, depois de uns 20 anos estou voltando para o desenvolvimento de sistemas e é incrível como que DDD é muito parecido com que utilizamos na década de 90 com o DFD, DER e MER. Mesmos objetivos, montar o dicionário de dados, criar contextos e montar a relação entre eles!
Agora eu te pergunto, você que já viu e passou por todas essas techs, qual a diferença e porque diabos reinventar a roda, se já existiu um modelo com as mesma caracteristicas ?
Parabéns por mais esse conteúdo Weslley, você consegue simplificar muito os assuntos. Gostaria que, se possível, você fizesse um vídeo sobre single sign on em microserviços. Grande abraço!
Perfeito o vídeo Weslley. Acredito eu que apesar de termos o privilégio de ter tantos conteúdos técnicos legais na nossa área assim de forma gratuita, vejo que ainda há um desequilíbrio do que é mais importante na construção de um sistema. A gente inicia a carreira de certa forma orientado à tecnologias específicas, linguagens específicas sendo que toda a parte de modelagem é deixada de lado. Infelizmente pra mim toda aquela teoria bacana aprendida na universidade nas disciplinas de Engenharia de Software no final das contas, quando vamos pro mercado vemos que são secundárias. Um exemplo que vale pra mim pelo menos é que no meu atual emprego a primeira coisa que questionei em relação aos sistemas à qual seria responsável era se tinha algum documento de especificação de requisitos, diagrama de classes, etc... Só nada. Mas o foco recente no mercado em cima do DDD me deu uma certa esperança quanto à isso.
Uma dúvida, Júnior: sabendo que podemos ter duas classes/entidades "Cliente" em contextos diferentes, como fica o nome da tabela no banco, se ambas as entidades têm o mesmo nome? Entendo que, em microsserviços pode até funcionar, mas para Monólito que utiliza DDD no seu Domain, com um único banco?
25:13 cara, eu acho interessante começar com use cases, utilizando alguns elementos de UML, e daí partir para o levantamento inicial do domínio. Use cases são um ótimo ponto de partida, e como eles são bastante extensíveis, você pode melhorá-los ao longo do projeto, à medida que a linguagem e os contextos se desenvolvem. No final eles serão um ótimo recurso visual para que qualquer desenvolvedor entenda de cara o que se espera do sistema. Sem use cases, precisamos ler user stories e montar tudo isso mentalmente.
Muito bom, mas eu faria algumas observações. 1. Na minha visão, catálogo, pagamento, lista etc. não seriam domínios. Domínio é o espaço do problema, normalmente a área onde o sistema roda a solução para o problema. Ou seja, sugiriria que o Domínio fosse o Netflix em si, já que não se trata de uma área corporativa tal como um restaurante ou uma clínica médica. A partir daí, traçaria os sub-domínios, representados por bouded contexts. E aí vem minna principal observação, os BC deveriam representar áreas de responsabilidade diferentes, ou seja, integração com parceiros, financeiro, player do cliente, player de usuário free. Esses dois últimos claramente possuiriam um núcleo compartilhando referente ao PLAYER. Mas o primeiro possuiria opções de off-line enquanto o segundo teria a incorporação de propagandas compulsórias. 2.linguagem ubiqua nasce dos cenarios de negócio (event storming) e nao de estórias de usuário. Não se deve também restringir os termos a substantivos. Além disso, cada termo deveria ser definido (se existir) em cada contexto delimitado. Exemplo, faltou um bounded context chamado Aquisições. Assim, o termo Video para esse BC significa um produto adquirido pelo serviço de streaming, enquanto para o assinante, representa um filme ou série que ele deseja assistir. Aliás, os contextos delimitados normalmente referem-se a subdomínios do problema. 3. Bouded context é padrão para espaço do problema e não dá solução. Então acho perigoso mencionar APIs nesse momento.
Excelente video. Vi o termo diversas vezes e li artigos, ou videos, curtos sobre o assunto Nunca fixei o contexto 100% ate agr, quando vi o seu conteudo kkkkkkk Ate me senti burro quando vc disse que o DDD é facil de entender
Excelente conteúdo. Parabéns. Sobre esperar ver código quando se fala de DDD, é uma questão de foco. DDD é uma disciplina de análise de sistemas; não de programação.
Fiquei aqui com uma dúvida no 35:45. Se o catálogo é o domínio principal e o perfil é o auxiliar, vc disse que o perfil é quem deverá se adaptar a mudança do catálogo. No entanto, não é o que acontece na maioria dos serviços de streaming. Quando vc muda o perfil,o catálogo muda completamente. Por exemplo, quando vc muda pra um perfil infantil, a prioridade do catálogo é trazer conteúdos infantis .
Opa amigo, espero que consiga ajudar. A forma que os dados sao fornecidos pelo Catalogo nao muda, por exemplo, se no meu dominio de Catalogo eu exponho a funcao PegarMinhaLista, e eu mudo para o Perfil Infantil, eu nao vou alterar o PegarMinhaLista para PegarMinhaListaInfantil, vai continuar a mesma coisa por que o Catalogo nao tem que mudar sua forma de "fornecer", ja no perfil eu tenho que consumir o "PegarMinhaLista" porem os dados que eu vou obter ou a forma de tratar os dados obtidos vao ser diferentes. Espero que tenha feito sentido.
Acho que a definicao de Servicos de Domino (Domain Services) no minuto 55:05 esta errada. Essa nao seria a definicao de Servicos de Aplicacao (Application Services)? Pois os Servicos de Aplicacao que consomem recursos da camada de infraestrutura. Os Servicos de Dominio deveriam conter apenas regra de negocio, e nao ter nenhuma relacao com repositorios, envio de email e etc (detalhes da infraestrutura). Ou isso se aplica apenas a Clean Architecture?
Muito bom! Só não entendi uma coisa, a regra de negócio vai ficar na entidade ou no service? e outra coisa, o service seria equivalente a um controller?
Pelo que entendi, a entidade você só define a estrutura e métodos de validação. Ja no serviço você constrói a entidade e implementa as regras de negócio ali. O fluxo seria Controller > Service > Entidade (constrói a entidade) > Repositório (persiste a entidade).
Ola, boa noite. Eu fiquei com uma dúvida durante o slide do minuto 39 Context Map.. Existe um limite ou um numero máximo ideal para domínios principais? Qual a boa pratica neste caso? Por que se num primeiro entendimento de contexto, você obter, sei lá, 8 domínios principais, acredito que há algo errado no entendimento talvez, não me parece correto eu ter muitos domínios principais, correto? Qual sua opinião sobre isso?
@@gregorifelicio6030 acredito que o nivel de aplicabilidade/aprendizado em relacao a cada um seja diferente, o que me faz pensar, qual é o "indicado" para utilizar num sistema escolar de porte pequeno.
Muito boa aula, ótimo trabalho. Pelo meu pontos de observação vc manteve o mesmo modelo teórico de tantos outros materiais na internet. A minha grande duvida com DDD é com a parte de entidades. Se vc observar na sua aula. Vc demostra duas entidates dentre os objetos agregados. Porem o seu repositório so considera uma (pagamento). Mesmo sabendo que em uma aplicação real, a transação e crucial para um sistema de pagamentos. O que vc chama de (Value object) por exemplo e uma informacao que pode ser persistida em banco de dados. Ela é de grande importancia para alguns segmentos. Mas no seu exemplo ela é tratada como um "tipo" simplesmente. E vc não considerou o vínculo que ela deveria ter com o assinante. No seu modelo, um pagamete tem relação com a assinatura, como seria este relacionamente. Se vc observar o status da assinatura pode mudar por consequecia do pagamento. Em DDD estes exemplos incompletos que encontramos ate mesmo no livro do Eric tornam a implementacao muito dificil. Tanto que até hj nunca vi uma implementacao de DDD que pudessemos considerar 100% correta. Assim como a sua que possui espaços em branco. Mas valeu, foi um grande trabalho e tenho certeza que demandou um esforço considerável.
Uma coisa que não entendo é porque insistem em chamar subdomínio de domínio. Outra coisa foi como achar todos aqueles subdomínios a partir de um único caso de uso.
Melhor explicação que já vi até agora nesses últimos anos. O pessoal por ai filosofa demais e não da para entender nada, você foi inclivel.
Pp
Melhor explicação de DDD que já vi. A única que consegui entender com facilidade. Excelente!
Sem exageros, de todos os vídeos que encontrei no TH-cam sobre DDD, este é de longe o melhor! 💡💡
Esse vídeo é perfeito para quem nunca entendeu DDD, sempre achou algo abstrato demais, e nunca conseguiu implementar na prática. Parabéns pelas explicações!
Sensacional, parabéns. Muito conteúdo mas explicado de forma muito didática. Muito Obrigado
Melhor canal de conteúdos de tecnologia backend, frontend , arquitetura e Devops. Fã demais !
Excelente conteúdo! Acabei de começar a trabalhar como Dev e o sênior pediu que eu estudasse sobre DDD e clean code antes de começar a codificar. Fora aprender React e Node (eu venho do Java kkk).
Cara, que vídeo sensacional, explica tudo muito bem de maneira progressiva do inicio ao fim. Por mais que falem que se mais usa em apps grandes, da perfeitamente pra usar os mesmos princípios em modelagens de programas bem mais simples, ajudando assim a documentar melhor o fluxo.
Esse canal é top, melhor qualidade de conteúdo de desenvolvimento de software do TH-cam.
Caraio mano. Nunca vi uma didática tão perfeita sobre um tema que pra mim parecia absurdo. O pessoal enfeita demais tornando tudo romantizado e você conseguiu tornar prática essa teoria e trazer mais pra realidade. Muito bom mano. Parabéns!
Excelente vídeo. Parabéns!
Super Concreto Will, a partir daí surgem algumas duvidas e estou pensando em como aplicar isso aqui em Portugal para os sistemas do governo para agregar valor, tanto no negocio quanto no desenvolvimento. Mas como aqui quase 100% dos projetos são monolitos, vou tentar abstrair para iniciar algo com DDD.
Valeu a aula Will.... vc é o kara!
Melhor explicação sobre DDD até agora. PArabens !!! Simples e direta...exemplificando de forma clara.
Show de explicação sobre DDD!! PARABÉNS Wesley!!!
Obrigado pelo conhecimento compartilhado, foi uma excelente explicação.
Weslley, que conteúdo! Quem já conhecia mas não havia consolidado o entendimento, agora conseguiu consolidar. Parabéns pela apresentação e clareza na transmissão do conhecimento. Eu gostaria de saber como aplicar a segunda parte, onde teríamos os microsserviços e se possível sob uma arquitetura Hexagonal ( ports and adapters).
Esse video é sensacional, acredito que deveria ser legendado em inglês para aumentar seu alcance. Eu com certeza indicaria para amigos aqui (moro fora do país)
Finalmente!! Finalmente entendi esse tal de DDD, que não significa Discagem Direta à Distância (os mais antigos devem se lembrar dos "orelhões" azuis rsrsrs)
Bha muito top essa explicacao, gosto muito dos teus videos. A didatica é sensacional!! Parabens
Muito boa a explicação Wesley.
Obrigado pela aula, resumiu completamente o livro sem deixar faltar nenhum detalhe.
Essa explicação salvou minha vida no trabalho!! Valew Weslley!!!!
Obrigado pelo conteúdo! Deus abençoe.
Muito obrigado Wesley, muito progresso pra vc, pois vc passa isto pra gente...VIDA LONGA.
Formei em 98 em Ciência da Computação com ênfase em análise de sistemas, minha carreira foi focada em Redes, especialização, mestrado e doutorado, depois de uns 20 anos estou voltando para o desenvolvimento de sistemas e é incrível como que DDD é muito parecido com que utilizamos na década de 90 com o DFD, DER e MER. Mesmos objetivos, montar o dicionário de dados, criar contextos e montar a relação entre eles!
Agora eu te pergunto, você que já viu e passou por todas essas techs, qual a diferença e porque diabos reinventar a roda, se já existiu um modelo com as mesma caracteristicas ?
Vídeo muito bem explicado, parabéns!!
Melhor vídeo que ja assisti sobre o assunto. Sensacional!
Conceito explicado bem e de forma simples. Parabéns!!!
A melhor aula sobre DDD que já vi.
Muito bom quando alguém que sabe o que está falando também sabe falar. DDD desmistificado em 1h. Parabéns e obrigado!
Grande aula! 👏👏
Melhor explicação de DDD!
Excelente explicação! Aprendi bastante. Obrigado por compartilhar 👍
Aula top! Parabéns! Gratidão!
Melhor explicação que encontrei sobre DDD, obrigada!
Parabéns por mais esse conteúdo Weslley, você consegue simplificar muito os assuntos. Gostaria que, se possível, você fizesse um vídeo sobre single sign on em microserviços. Grande abraço!
Obrigado Weslley pelo esclarecimento, estava com muitas dúvidas e este seu vídeo me ajudou a ter uma base de como funciona o DDD.
parabens! um dos melhores resumos sobre ddd que assisti. Obrigado.
Irei começar um projeto aplicando DDD, realmente esclareceu muita coisa, ótimo vídeo, parabéns!
Fantástico! Parabéns por essa aula!
uau! you are amazing !! your speech is so clear and easy to understand the subject.
Até que enfim alguém explicando DDD de verdade e não só copia e cola código
Perfeito o vídeo Weslley. Acredito eu que apesar de termos o privilégio de ter tantos conteúdos técnicos legais na nossa área assim de forma gratuita, vejo que ainda há um desequilíbrio do que é mais importante na construção de um sistema. A gente inicia a carreira de certa forma orientado à tecnologias específicas, linguagens específicas sendo que toda a parte de modelagem é deixada de lado. Infelizmente pra mim toda aquela teoria bacana aprendida na universidade nas disciplinas de Engenharia de Software no final das contas, quando vamos pro mercado vemos que são secundárias. Um exemplo que vale pra mim pelo menos é que no meu atual emprego a primeira coisa que questionei em relação aos sistemas à qual seria responsável era se tinha algum documento de especificação de requisitos, diagrama de classes, etc... Só nada. Mas o foco recente no mercado em cima do DDD me deu uma certa esperança quanto à isso.
Perfeito ... Parabéns pelo trabalho realizado.
Melhor aula e explicação, parabéns
Conteúdo muito bom parabéns
Conteudo top demais
Muito bacana, eu estava começando a procurar conteúdos do DDD procurando códigos rs... e seu vídeo abriu meus olhos... vlw
muito bom.. parabéns
Que explicação maravilhosa! Obrigado!!! 🚀🚀🚀
Woow awesome class my friend really love it
Explicação top!
Ótima explicação!
show. parabens!
Muito legal amigo tamos juntos valeu é nós
Parbéns. Tua linguagem vai direto ao ponto.
Caralho, sensacional. Tô sem palavras aqui pro tanto de informação que acabou de me bombardear
Muito boa explicação!
Excelente conteúdo!!
Uma dúvida, Júnior: sabendo que podemos ter duas classes/entidades "Cliente" em contextos diferentes, como fica o nome da tabela no banco, se ambas as entidades têm o mesmo nome? Entendo que, em microsserviços pode até funcionar, mas para Monólito que utiliza DDD no seu Domain, com um único banco?
Excelente explicação! Obrigado!
Que aula! Muito obrigado Weslley por mais este conhecimento repassado!
Cara muito obrigado, excelente conteúdo, diferente de todos os outros. Parabéns!
Muito bem explicado! Muito obrigado!
Nossa! Parabéns pelo vídeo, uma aula incrível. Obrigada!
Muito bom!!!
Excelente Weslley! Muito obrigado pela ajuda!
Aulas teóricas geralmente são chatas pra kct. Mas a sua foi MUITO BOA!!! Parabéns e muito obrigado por compartilhar este conhecimento!
25:13 cara, eu acho interessante começar com use cases, utilizando alguns elementos de UML, e daí partir para o levantamento inicial do domínio. Use cases são um ótimo ponto de partida, e como eles são bastante extensíveis, você pode melhorá-los ao longo do projeto, à medida que a linguagem e os contextos se desenvolvem. No final eles serão um ótimo recurso visual para que qualquer desenvolvedor entenda de cara o que se espera do sistema. Sem use cases, precisamos ler user stories e montar tudo isso mentalmente.
Muito bom, mas eu faria algumas observações.
1. Na minha visão, catálogo, pagamento, lista etc. não seriam domínios. Domínio é o espaço do problema, normalmente a área onde o sistema roda a solução para o problema. Ou seja, sugiriria que o Domínio fosse o Netflix em si, já que não se trata de uma área corporativa tal como um restaurante ou uma clínica médica. A partir daí, traçaria os sub-domínios, representados por bouded contexts. E aí vem minna principal observação, os BC deveriam representar áreas de responsabilidade diferentes, ou seja, integração com parceiros, financeiro, player do cliente, player de usuário free. Esses dois últimos claramente possuiriam um núcleo compartilhando referente ao PLAYER. Mas o primeiro possuiria opções de off-line enquanto o segundo teria a incorporação de propagandas compulsórias.
2.linguagem ubiqua nasce dos cenarios de negócio (event storming) e nao de estórias de usuário. Não se deve também restringir os termos a substantivos. Além disso, cada termo deveria ser definido (se existir) em cada contexto delimitado. Exemplo, faltou um bounded context chamado Aquisições. Assim, o termo Video para esse BC significa um produto adquirido pelo serviço de streaming, enquanto para o assinante, representa um filme ou série que ele deseja assistir. Aliás, os contextos delimitados normalmente referem-se a subdomínios do problema.
3. Bouded context é padrão para espaço do problema e não dá solução. Então acho perigoso mencionar APIs nesse momento.
Muito bom ! me ajudou muito!!
Excelente conteúdo. Parabéns.
Excelente video.
Vi o termo diversas vezes e li artigos, ou videos, curtos sobre o assunto
Nunca fixei o contexto 100% ate agr, quando vi o seu conteudo kkkkkkk
Ate me senti burro quando vc disse que o DDD é facil de entender
Excelente conteúdo. Parabéns.
Sobre esperar ver código quando se fala de DDD, é uma questão de foco.
DDD é uma disciplina de análise de sistemas; não de programação.
Parabéns! Muito legal, obrigado!
É bem interessante.
Muito bom o conteúdo e os exemplos também, parabéns e obrigado.
Incrível conteúdo, muito obrigado!
Pq
🐱
Muitoo bomm
Fiquei aqui com uma dúvida no 35:45. Se o catálogo é o domínio principal e o perfil é o auxiliar, vc disse que o perfil é quem deverá se adaptar a mudança do catálogo. No entanto, não é o que acontece na maioria dos serviços de streaming. Quando vc muda o perfil,o catálogo muda completamente. Por exemplo, quando vc muda pra um perfil infantil, a prioridade do catálogo é trazer conteúdos infantis .
Opa amigo, espero que consiga ajudar. A forma que os dados sao fornecidos pelo Catalogo nao muda, por exemplo, se no meu dominio de Catalogo eu exponho a funcao PegarMinhaLista, e eu mudo para o Perfil Infantil, eu nao vou alterar o PegarMinhaLista para PegarMinhaListaInfantil, vai continuar a mesma coisa por que o Catalogo nao tem que mudar sua forma de "fornecer", ja no perfil eu tenho que consumir o "PegarMinhaLista" porem os dados que eu vou obter ou a forma de tratar os dados obtidos vao ser diferentes. Espero que tenha feito sentido.
Acho que a definicao de Servicos de Domino (Domain Services) no minuto 55:05 esta errada. Essa nao seria a definicao de Servicos de Aplicacao (Application Services)?
Pois os Servicos de Aplicacao que consomem recursos da camada de infraestrutura. Os Servicos de Dominio deveriam conter apenas regra de negocio, e nao ter nenhuma relacao com repositorios, envio de email e etc (detalhes da infraestrutura).
Ou isso se aplica apenas a Clean Architecture?
Excelente explicação! 👏🏼👏🏼👏🏼
Valeu Weslley! Agora sim não vou pererecar no DDD
Boa tarde 👍👌✌
ótima aula professor :)
Mandou muito bem!
Muito bom! Só não entendi uma coisa, a regra de negócio vai ficar na entidade ou no service? e outra coisa, o service seria equivalente a um controller?
Pelo que entendi, a entidade você só define a estrutura e métodos de validação. Ja no serviço você constrói a entidade e implementa as regras de negócio ali. O fluxo seria Controller > Service > Entidade (constrói a entidade) > Repositório (persiste a entidade).
aula excelente! alguem tem o link do slide?
muito bom!
Ola, boa noite.
Eu fiquei com uma dúvida durante o slide do minuto 39 Context Map..
Existe um limite ou um numero máximo ideal para domínios principais?
Qual a boa pratica neste caso? Por que se num primeiro entendimento de contexto, você obter, sei lá, 8 domínios principais, acredito que há algo errado no entendimento talvez, não me parece correto eu ter muitos domínios principais, correto?
Qual sua opinião sobre isso?
Isso que eu chamo de aula!
Mas essa mosquinha incomodou hein kkkkkkkkkk
vcs usaram mvc ou ddd num sistema escolar de pequno porte?
@@gregorifelicio6030 acredito que o nivel de aplicabilidade/aprendizado em relacao a cada um seja diferente, o que me faz pensar, qual é o "indicado" para utilizar num sistema escolar de porte pequeno.
Obrigado
Eu so quero saber hoje
Odeio aulas teoricas, assisti a tua ate o final totalmente interessado, parabens, 1 hora gasta minha com valor agregado
Então é isso? Pensei que fosse algo de outro mundo.
Professor vc foi show, mais esqueceu de colocar seu nome no video...kkkk como vejo a implementação..
Muito boa aula, ótimo trabalho.
Pelo meu pontos de observação vc manteve o mesmo modelo teórico de tantos outros materiais na internet.
A minha grande duvida com DDD é com a parte de entidades.
Se vc observar na sua aula. Vc demostra duas entidates dentre os objetos agregados.
Porem o seu repositório so considera uma (pagamento). Mesmo sabendo que em uma aplicação real, a transação e crucial para um sistema de pagamentos.
O que vc chama de (Value object) por exemplo e uma informacao que pode ser persistida em banco de dados. Ela é de grande importancia para alguns segmentos.
Mas no seu exemplo ela é tratada como um "tipo" simplesmente. E vc não considerou o vínculo que ela deveria ter com o assinante.
No seu modelo, um pagamete tem relação com a assinatura, como seria este relacionamente. Se vc observar o status da assinatura pode mudar por consequecia do pagamento.
Em DDD estes exemplos incompletos que encontramos ate mesmo no livro do Eric tornam a implementacao muito dificil. Tanto que até hj nunca vi uma implementacao de DDD que
pudessemos considerar 100% correta. Assim como a sua que possui espaços em branco.
Mas valeu, foi um grande trabalho e tenho certeza que demandou um esforço considerável.
Uma coisa que não entendo é porque insistem em chamar subdomínio de domínio. Outra coisa foi como achar todos aqueles subdomínios a partir de um único caso de uso.
brabo