Salve, Deus da beleza! Continuamos a saga aqui no Domain Dreaming Design. Essa aula serve para a gente já poder responder uma pergunta inicial que pode ficar conturbando a nossa cabeça, etc. Que decisões que eu vou tomar aqui no meio do meu projeto? A gente começa a se questionar como que vai ser criada a lei de estrutura de pastas, tem que ser assim, assado, senão eu não estou utilizando o DDD. Eu quero deixar claro para vocês o seguinte, não existe uma lei, não existe algo taxado em pedra, não existe uma decisão necessariamente perfeita. Isso depende muito do contexto da sua equipe, do purismo ou não que você vai usar o DDD. Eu tenho aqui uma estrutura de projetos do meu framework. Já me deu aqui a pasta source. Inclusive, se eu ficar rodando aqui outros comandos com ele, ele vai até criar outras pastinhas aqui para mim. Vai montando até a forma dele de trabalhar. Tem problema se eu usar os artefatos do DDD misturado com o meu framework? A princípio, não. A princípio, não. Mas você tem que saber que se você vai espalhando, misturando o coração do seu código com o seu framework, então você acaba tendo uma mescla das funcionalidades, dos conceitos, das terminologias. Aí, se você precisar depois fazer mudanças mais drásticas, você pode ter problemas. Mas, às vezes, o seu projeto cabe. E é essa visão que eu quero dar aqui para vocês. Eu posso também usar o DDD dentro da minha pastinha source, dentro do meu framework, tendo certa mistura com o meu framework também. Não tem problema. Desde que você saiba as consequências disso. Ah, eu posso usar ali, às vezes, uma camada de serviço que o meu framework tem e só criar as minhas entidades e até, às vezes, o meu repositório misturar. Você pode tomar essas decisões. Eu vou falando isso durante as aulas. pode tomar essas decisões. Eu vou falando isso durante as aulas. O que eu vou mostrar aqui é justamente uma forma pura de trabalhar com o DDD. A gente vai criar o nosso projetinho, ele vai ficar numa pasta que eu poderia colocar depois num outro projeto qualquer, num projeto express, num qualquer coisa de JavaScript com Node, que ele vai funcionar. Ele não vai depender do nest para poder fazer a execução. Então, a gente vai trabalhar de forma pura. Mas mesmo assim, eu vou colocar aqui o meu arroba core, que é onde nós vamos desenvolver, ele vai ficar dentro do meu projeto, não tem problema nenhum. Às vezes, você criar subprojetos aqui até seria mais complicado. Então, nós vamos separar os nossos artefatos em três pastas. Em domínio, nós vamos colocar coisas específicas do domínio como entidades, agregados, eventos de domínio. Na pasta application, vão ser os serviços de aplicação, inclusive não dentro de domínio aqui folder application e infra que é a nossa infraestrutura ou seja, as coisas que a gente precisa ali específicas de bibliotecas apesar que o próprio Nest já está englobando que que é o que a gente está usando aí, o Framework para principalmente ter uma API depois que é o nosso resultado final. Essa estrutura de passos aqui também é uma recomendação eu gosto de utilizá-la justamente porque deixa claro as intenções. Lembra do que o Evans fala no livro que o código é o projeto e o projeto é o código. Então, quanto mais claro você deixar os nomes também, a gente está falando de terminologia, de linguagem ubíqua, fica mais fácil para você poder fazer a relação de tudo que é discutido no meio do projeto. Mas se você quiser não fazer essa separação, às vezes tem gente que junta domínio com a aplicação, não tem problema. A questão é que você tem que ter consciência do que você está fazendo e não simplesmente seguir alguma coisa só porque alguém disse. Dessa forma aqui, eu sei o que está dentro da aplicação, como são os application services, a gente vai ter a separação aqui do domínio. E infraestrutura, eu sei que toda vez que eu fizer alguma coisa de repositório, de biblioteca, etc., eu sei que está nessa fase. Também para fins didáticos aqui vai ficar muito mais fácil de vocês entenderem. Maravilha, pessoal. Então, vamos seguindo a nossa saga. É isso aí. E até a próxima.