Salve Deus, beleza? Continuar essa saga aqui no Domain do Real Design. Nós vamos responder uma pergunta nessa aula, que é uma pergunta muito comum, porque DDD é um assunto muito atrativo. Às vezes a gente tende a achar que é bala de prata. E uma sabedoria que nós temos que ter nessa área é que nada é bala de prata, tudo você precisa analisar contexto. Mas no início do livro do Volkwarnon, ele comenta sobre quando que o DDD seria recomendado para o meu projeto, quando não seria. E aí ele tenta criar aqui um scorecard, que é justamente essa tabela que eu estou mostrando. Mas essa tabela aqui não é nada escrito em pedra. Não significa que a gente vai se basear necessariamente nisso. É um exercício de reflexão para avaliar se o DDD cabe ali para o nosso projeto ou não. Então, ele coloca alguns pontos. Esses pontos são numerados de 0 a 5. Na verdade, eles são pontuados, e aí você vai analisar se aquilo ali é verdade para o seu projeto. Se for verdade, você vai somar aqueles pontos. Aí a pergunta que ele faz é, seu projeto tem uma pontuação de 7 pontos ou mais? tem uma pontuação de 7 pontos ou mais, se você tiver 7 pontos ou mais, então, pode ser adequado usar o DDD. Então, essa é a questão. Pode ser adequado usar o DDD. Vamos voltar aqui, na verdade, para a nossa modelagem, que a princípio nós temos esses subdomínios aqui. E nós temos os dois subdomínios que são os cores no momento. E aí, quando a gente pega toda essa modelagem, vem na cabeça ou é implícito que, se eu vou trabalhar com o DDD nesse projeto, então todos os meus subdomínios eu tenho que trabalhar com a parte tática. Daqui a pouco a gente vai falar sobre essa parte tática, principalmente a tática que vai chegar lá nas entidades, agregados e etc. E não necessariamente. O DDD é para que você resolva um problema complexo de negócio. Então, não tem problema nenhum. Imagina que essa aplicação toda aqui fosse um monolito. A gente não vai nem discutir microserviços nesse momento. Mas eu precisaria trabalhar com os conceitos do DDD em todos os subdomínios? Não, não preciso. Você pode pegar as partes mais complexas, ou a parte que você considerou ali que é necessário ter o DDD para reduzir essa complexidade e trabalhar com o DDD. E as outras partes não. Aí você vai desenvolver lá, utilizando diretamente os seus ORNs, sem tantas camadas e etc. Porque determinadas áreas, elas não representam um grande risco. Basicamente, às vezes, são alguns crudes que você tem que fazer ali, o seu framework já resolve. Você acrescenta DDD e outras coisas como Clean Architecture, arquitetura hexagonal, acabam criando várias camadas, você faz um crude premium. Isso que você acaba fazendo. Não tem necessidade. Então, a gente precisa entender aonde é aplicável, porque eu não quero ficar gastando tempo, dinheiro, aumentando a burocracia, porque o DDD vai fazer com que você tenha várias camadas no seu software, vai criar mais arquivos, vai adicionar uma certa complexidade para que você lide com a complexidade desse software. Então, lá naquela tabela, a primeira coisa que ele está falando aqui... Ah, espera aí. Se a sua aplicação for completamente centrada em dados e qualificar verdadeiramente para uma solução crude pura, em que você tem ali as operações simples de criar, ler, consultar e etc., sua equipe só precisa colocar um rosto bonito em um editor de banco de dados. E muitas vezes, muitas das vezes, o software que a gente vai desenvolver é isso ou um pedaço do software é isso. A gente está criando uma interface bonita para o usuário não manipular o banco de dados diretamente. Então, ele está recomendando aqui nesse caso. Se você tem isso aí, não precisa nem cogitar. Inclusive, é a menor pontuação, a pontuação zero. Depois, ele avalia que se o seu sistema tiver 30 ou menos operações de negócio, e aqui ele está falando quando a gente pensa assim, o que é operação de negócio, e aqui ele está falando, quando a gente pensa assim, o que é operação de negócio? É o criar, é o consultar, ou a minha classe ali que tem aquelas operações. O que ele está falando, na verdade, não são as classes que a gente vai ter no sistema. Imagina que você tem as operações. A gente pode se basear Nas histórias de usuário Pegando aí Métodos ágeis, você tem ali as histórias do usuário Então eu tenho Menos de 30 Não significa necessariamente Que o seu sistema é simples Mas ele está dizendo aqui, olha 30 histórias, pode ser que o seu sistema é simples É simples Se ele dá com 30 ou menos Então, pode ser que seu sistema é simples, é simples se ele dá com 30 ou menos. Então, pode ser que não seja também adequado. E, nesse caso, a pontuação também é baixa. Cada vez que a gente vai avançando, a pontuação fica mais alta porque cada vez mais a gente está avaliando a complexidade do software. Ah, tá, mas agora eu estou avaliando aqui no intervalo de 30 a 40. Esse número é muito simbólico, ele é totalmente arbitrário. Por que 30? Por que não 29? Mas só para a gente poder entender que muitas das vezes a gente quer aplicar o DDD num software inteiro ou em pedaços do software que não tem necessidade nenhuma. Se você não aplicar ali, não vai mudar ou não vai impactar na manutenção, no custo daquele software. Por quê? A gente quer aplicar justamente onde mais vale a pena. Algumas vezes, aplicar em todo o software vai ser o necessário, porque você viu ali, você sentiu. Então, o Evans fala muito disso no livro, de você usar o seu pressentimento, a sua experiência, a sua intuição. E pode parecer um pouco subjetivo, mas isso é interessante também, porque a gente meio que sabe se aquilo ali vai ser complexo ou não. Inclusive, ele está citando ali, às vezes a sua equipe já está muito experiente em resolver aquele problema de negócio que aconteceu, aquele domínio que surgiu para a gente poder desenvolver um software. Então, a equipe já tem essa experiência ali, é uma solução um pouco linear, então talvez implementar o DDD não seja factível. Mas surgiu um domínio aqui que a gente nunca desenvolveu nada nesse sentido, tem muitas coisas obscuras nisso. Então, partindo do espaço do problema aqui e o design estratégico, só isso aqui já vai dar uma visão, já vai nos ajudar a entender, então aqui a gente já está usando o DDD e muitas das vezes também, você pode usar o DDD estratégico, que é aquele que a gente estava falando, que é justamente ter ali a visão do problema do que a gente estava falando, que é justamente ter ali a visão do problema, do que a gente tem que fazer. E, no final das contas, o design tático você não precisaria desenvolver. Eu posso ter, usar o DDD num projeto menor, com uma visão estratégica, mas ali na tática, a gente vai acabar mesmo utilizando o RM, as coisas do próprio framework, já vai ser mais que suficiente, porque DDD é usado sempre para projetos complexos. Lembra do que o Vernon falou lá nas aulas dele, ele estava falando lá de, tem uma empresa com vários níveis de hierarquia, várias equipes de desenvolvedores. A gente pensa muito no DDD, na solução técnica, mas lembra que é questão de comunicação. Então, é criar os contextos, separar as linguagens nos contextos, entender a relação entre esses caras. Então, a gente está falando de solução de negócio, depois pensando no lado técnico. Então, não tem problema nenhum se você não aplicar puramente o DDD ali no meio de uma parte do projeto ou no seu projeto. Se você fez aqui uma análise dos contextos, já é o primeiro passo. Então, essa tabela aqui, ela meio que nos dá mais os questionamentos do que é. Não é para você poder fazer uma somatória aqui e ver se tem sete ou mais. Agora eu vou usar o DDD. Espero que isso tenha ficado claro. No final aqui ele fala assim, olha, se você não entende o domínio, porque ele é novo, à medida que você e a sua equipe sabem, ninguém fez isso antes. Ninguém tem ideia disso. Provavelmente significa que ele é complexo. Alguém está te falando algum problema ali, você não tem a mínima ideia do que está acontecendo. Então, o que você vai ter que fazer? Sentar com os domain experts e fazer modelagem e refinar e e questionar, e etc. Então, nesse caso, o DDD vai ajudar com que a gente organize todas essas ideias. Agora, se está com uma solução linear, os domain experts vão ser indispensáveis ali, mas não é uma solução que você vai precisar de muito refinamento. Sua equipe já trabalha com isso. Talvez até o uso tático do DDD, criar as entidades, os agregados, uma solução que você vai precisar de muito refinamento e tal. Sua equipe já trabalha com isso, talvez até o uso tático do DDD, criar as entidades, os agregados, se vocês quiserem trabalhar dessa forma, já vai ser mais linear também. Mas a questão que a gente tem que entender é que o uso de DDD, ele envolve um custo de tempo e também quando chegar lá na parte prática, ele vai envolver um custo de tempo e também quando chegar lá na parte prática, ele vai envolver um custo também no software. Você vai tender a criar mais arquivos, mais camadas, e não necessariamente isso pode ser benéfico para o seu contexto. Maravilha, pessoal! Então, vamos seguindo a nossa saga. É isso aí. E até a próxima.