Salve, Daz, beleza? Agora, finalizando o nosso módulo de Domain Driven Design, foi uma trajetória muito complicada, porque DDD, definitivamente, não é algo simples. A gente viu aqui que requer muita experimentação. Essa é a lição que eu deixo aqui para vocês. experimentação, tá? Essa é a lição que eu deixo aqui pra vocês. De fato, você precisa ler pelo menos os livros do Evans e o... o livro do Evans e o do Vernon, apesar que o Vernon também tem outros livros sobre DDD, tem outros sobre DDD também, que você pode buscar, mas pra você poder entender o domínio do design, é necessário que você pelo menos leia o livro azul e o livro vermelho. Mas para você poder, de fato, ficar bom em DDB, você precisa praticar. Você tem que pegar um problema aí da sua empresa ou alguma aplicação que você queira montar e ir desenvolvendo ali os subdomínios, começar com o design estratégico, depois o design tático, ir modelando os agregados, trabalhando com testes principalmente para garantir que tudo está funcionando e fazendo e vendo como que isso está feito. Porque o refinamento é assim, você vai conhecendo mais sobre o domínio, ele vai ficando mais apurado, você vai ficando mais experto e acontece o refinamento das entidades, do seu modelo e essa aplicação fica melhor. E assim você vai entender todos os desafios que estão associados. Em todas as linguagens de programação, a gente vai ter os seus devidos desafios, porque algumas vão ter algumas bibliotecas melhores, outras não. Então, a gente precisa saber contornar a parte técnica também. Mas DDD é aquela coisa que você vai ficar bom depois de você passar meses e mais meses e mais meses trabalhando. E é a lição que eu deixei lá atrás. DDD deve ser usado aonde cabe. Não é para você poder usar em todo lugar, não é bala de prata, não é resposta para todos os seus problemas. A gente vê aqui na nossa aplicação, a gente vê aqui na nossa aplicação o quanto de arquivos que precisam ser criados. Obviamente, isso aqui torna as coisas mais burocráticas, mas essa burocracia existe justamente para poder separar responsabilidades, separar camadas, permitir que a nossa manutenção ao longo do tempo não estrague esse software, que ele realmente satisfaça as necessidades de usuário. Não é para você poder pegar qualquer software simples e ficar fazendo essa implementação de DDD. No máximo, uma arquitetura hexagonal, uma camada de serviços, já seria suficiente. Mas, espero que vocês tenham gostado. Deu bastante trabalho para poder gravar esse módulo, mas é isso aí. O MBA está show de bola. Continuem mantendo os estudos e qualquer coisa estou disponível ali para poder tirar dúvidas e a nossa equipe também. Pessoal, agradeço mais a oportunidade de estar aqui com vocês nos cursos da Full Cycle e a gente vai se vendo aí pelos outros canais. Então, tchau pessoal, até a próxima.