Salve, Deus, beleza? Continuando a nossa saga aqui no Domain Dreaming Design, vamos começar a falar do design tático pelo primeiro quesito que todo mundo quer ver uma modelagem disso. Entrou numa aula de Domain Dreaming Design e você quer ver uma entidade. É o recurso mais procurado disso, mas eu tenho uma má notícia para você. Mas eu tenho uma má notícia para você. Porque entidade, a gente já chega no DDD com esse conhecimento. Porque normalmente você já trabalhou com framework ou com vários ORMs das linguagens de programação. Mas a má notícia é que essa entidade que você vê lá não é a entidade do DDD. Por que não? Porque quando a gente pega esses ORMs que você vê lá não é a entidade do DDB. Por que não? Porque quando a gente pega esses ORMs e vai modelar uma entidade, vamos pegar aqui o caso do nosso core, que é a parte de eventos. Aqui é a parte de eventos, a gente vai ter o evento. Então, o evento seria uma entidade. Então, vamos colocar aqui eventos. E o que que eventos terá? Aí você chega lá no seu RM e declara assim, vai ter um ID, uma data do evento e os spots. Além disso, essa entidade aqui vai ter as operações de criar, de fazer o update e de fazer a exclusão. tá beleza isso aqui não é uma entidade do DDD na verdade isso aqui a gente chama de uma entidade ela até é uma entidade ela pode ser considerada uma entidade porque a gente está fazendo uma modelagem ali na orientação a objetos, a gente está falando aqui principalmente da orientação a objetos, mas ela é uma entidade anêmica. Porque quando a gente olha aqui para eventos, eu sei dos dados e eu sei como que eu posso operacionalizar isso no banco. Criar, atualizar, excluir, não significa que uma entidade do DDD não possa ter essas operações. Mas essas restritas operações que estão previstas lá, em qualquer ORM, elas só descrevem como que você vai salvar em disco. Isso não é regra de negócio. Por isso que é anemia, porque é inexpressivo. E aí quando a gente acaba criando esse modelo aqui, as regras de negócio tendem a ficar diluídas pelo software, fazendo com que fique não claro, não fique cristalino ali, saber quais são essas regras de negócio. Fica até difícil de manter, porque você vai diluindo ela, você não tem ideia de como organizar essas regras de negócio, elas vão ficando em vários lugares. O que eu quero dizer aqui não é necessariamente modelo anêmico é ruim. Não. A gente precisa desse modelo anêmico justamente porque a gente vai pegar essa entidade e salvá-la no banco de dados, salvá-la de alguma outra forma. Mas o DDD faz que você pense em um domínio rico, na riqueza das regras de negócio, que vão estar cristalinas na entidade. Então, é difícil a princípio para a gente que está começando com DDD, isso foi difícil para mim também, quando eu comecei a estudar DDD há alguns anos atrás, porque a gente já vem totalmente contaminado, sabe aquela história que você vai na autoescola e alguém já te ensinou a dirigir antes e você está cheio de vícios, você já tem uma visão de como dirigir e ali com o instrutor do lado, você vai ter que largar esses vícios, a sua visão está poluída com uma série de manias e outras coisas que você deveria largar? Pois é. Então, um recado que eu já dou para vocês aqui sobre essa questão de entidades é que não é para você poder descartar o que você já sabe dos ORMs, do que você já trabalhou, mas a questão é deixar a sua mente aberta porque modelar uma entidade não é tão simples assim. Captar as regras de negócio dela não é tão linear. Muitas vezes compete um refinamento que você vai fazendo conforme o software vai avançando. Nos ORMs da vida, a gente só simplesmente delimita ali os dados e as coisas já vão funcionar. Muitas vezes no domínio, você vê que aquelas operações não fazem muito sentido, como que elas estão acopladas às regras de negócio, que vão transitar nesse fluxo inteiro. E aí você vai fazendo esse refinamento e muitas fazendo esse refinamento, e muitas vezes esse refinamento não implica necessariamente que você está mudando os dados. Não, os dados você já captou, você sabe que aqueles dados ali vão ser aqueles. Mas a regra de negócio para poder manipular e calcular esses dados, aí sim esse modelo anêmico não vai transparecer e não vai te ajudar sobre isso. E dependendo de como você vai modelar esse software, a gente acaba tendo duas entidades. Você pode ter a sua entidade, vamos colocar assim, anêmica. E a sua entidade rica. E aqui, obviamente, nós vamos trabalhar com uma outra visão. O modelo anêmico serve para que a gente possa transacionar com o banco de dados ou com o seu storage. E eventos, na verdade, normalmente a gente chama no singular, não seria eventos, seria evento. E é o evento de fato que vai trabalhar com as nossas regras de negócio do DDD e tende-se a criar esse modelo rico sem que tecnologia tenha impacto, sem que a gente fique preso à tecnologia. Isso é uma visão mais purista do DDD para permitir que o coração do software não dependa de bibliotecas, não dependa de frameworks, que ele não seja contaminado por essas tecnologias, que ele permaneça puro e estável. E as partes de infraestrutura do software é que vão cuidar dessa parte. E a gente vai ter ali o nosso domínio rico, isolado, domínio rico, isolado, e a nossa infraestrutura que vai depender desse domínio e não o contrário. Maravilha, pessoal. Então, a gente já teve essa visão sobre entidade, principalmente sobre a questão da entidade anêmica, e a rica nós ainda não chegamos nesse conceito, mas o que eu deixo de lição aqui nessa aula é, abra a sua cabeça. Porque eu já vi muitos alunos, quando começam a trabalhar com DDD, você começa a ficar travado, ou achando que aquilo não é de fato efetivo, porque você passou, às vezes, anos e mais anos trabalhando com anemia no meio do seu software, e quando você chega nisso aqui, é difícil pensar diferente essa entidade, porque você já está acostumado a fazer dessa maneira. Na prática, vai ficar bem mais claro essa visão ou insights do que a gente tem que considerar para poder fazer a captação desse modelo rico. Então, vamos continuar nossa saga. É isso aí. E até a próxima.