Salve, Deus, beleza? Continuando essa saga aqui no Domain Dreaming Design, na última aula nós estabelecemos a diferença entre o modelo rico e o modelo anêmico. A anemia, sempre quando a gente está trabalhando ali com as leads, porque elas estão preocupadas não com regra de negócio, mas com a persistência dos dados. Então agora vamos falar sobre o nosso modelo rico, que vai entrar ali as entidades, apenas um quesito do nosso modelo rico, que vai entrar ali as entidades. Apenas um quesito do nosso modelo rico. Como identificar uma entidade no DDD? Talvez seria a pergunta correta. Quando você tem algo ali no seu contexto delimitado, de eventos, a gente quer lidar com o evento. A gente sabe disso, certo? Para saber se ele seria uma entidade ou não, a gente quer lidar com o evento. A gente sabe disso. Para saber se ele seria uma entidade ou não, a primeira pergunta é eu devo diferenciar esse evento de outros? E obviamente a resposta é que sim. A gente quer que um evento seja diferente de outro que um parceiro esteja cadastrando. Mas a questão é, como diferenciar esse evento de outro? Por uma identidade. Então, a entidade é um objeto que nós queremos manipular, e quando eu estou falando de objeto, apenas é um termo que eu estou utilizando, não é porque é necessariamente orientação a objetos, eu poderia trabalhar com essa modelagem em outros paradigmas também. A questão é um grupo de informações que eu quero lidar em que lá dentro nós vamos ter essa identidade que vai diferenciar esse objeto de outros. Então a questão é, o que identifica esse evento que diferencia ele dos outros. Qual é a identidade desse cara? Talvez eu pudesse colocar aqui um código próprio, evento 001 talvez aqui pra poder ser sequencial, poderia ser um hash também, enfim, poderia ter alguma regra para poder determinar essa identidade. Então, eu teria também a data aqui, como outra informação da minha identidade, ela vai acontecer no dia 1º de janeiro de 2023. E tenho lá os meus spots. Quando eu vou determinar se esse evento é igual ao outro, eu não preciso comparar os spots, a data ou quaisquer outras informações. Eu apenas comparo a minha identidade. Não é assim que a gente aprende lá no banco de dados, que eu tenho a chave primária para a minha tabela e quando eu quero manipular aquele registro ou recuperá-lo, eu sempre consulto, ou tendo a maioria das, sempre a consultar pela chave primária. Então, isso aqui é um forte candidato a ser a chave primária lá na minha tabela do banco de dados. Mas vamos identificar aqui uma outra identidade que dá uma visão mais apurada sobre essa questão da identidade de uma entidade. Então, vamos supor que eu tenho uma pessoa. O que faz uma pessoa ser diferente das outras? Eu não estou falando no sentido, assim, aquele sentido filosófico, não. Estou falando no sentido de sistema. O que faz uma pessoa ser diferente das outras? Vamos colocar nome? Não, nome. Nós podemos ter pessoas com nomes repetidos. Não tem essa restrição, pelo menos aqui no nosso país, não tem. Aí, pensando em RG, RG não seria uma boa métrica também, porque a gente já sabe que uma pessoa pode emitir um RG por estado. Então, isso aqui não seria ruim, isso aqui não iria garantir que fosse, de fato, diferente um do outro. O que, de fato, faz com que uma pessoa seja identificada de forma diferente da outra. No Brasil, seria o CPF, porque uma pessoa não pode ter dois CPFs. Uma pessoa não pode mudar o CPF. Então, uma vez que eu estabeleci que eu tenho que identificar uma pessoa diferente da outra, que ela é uma entidade, ela vai ter uma identidade e essa identidade não se modifica. Ela vai nascer aqui com esse CPF e ela vai morrer com esse CPF. Ela não troca, uma pessoa não troca CPF. A gente está falando de uma regra de negócio. Então, quando eu for pesquisar lá no banco de dados, eu pesquiso pelo CPF. Quando eu vou verificar se uma pessoa é igual a outra, inclusive, olha como que é importante essa questão de ter uma identidade que realmente diferencia essa pessoa das outras. Posso ter um software jurídico em que se eu identificar essa pessoa pelo nome, eu poderia processar uma pessoa que não tem nada a ver com a situação, só porque está com o nome igual. Ah não, você quer abrir um processo aqui? Qual é o CPF dessa pessoa? Ah, eu não sei. Então, a gente não consegue abrir esse processo, porque a gente tem que saber, de fato, identificar essa pessoa. E aí vem perguntas mais técnicas. Ah, mas esse CPF, ele seria, então, uma chave primária lá no meu banco de dados? Ele é elegível para ser. E aí vem uma questão que normalmente é um mito que algumas pessoas têm com relação a DDD, que é a de sua decisão, banco de dados é umhe, a DDD não fala isso. É que normalmente a gente quer que as pessoas afastem a visão contaminada do banco para que ela pense mais nas regras de negócio. Mas o Banco de Dados tem essa interferência no modo que você vai trabalhar com as suas entidades. Porque dependendo do que você fizer, não adianta você criar uma entidade que não é nada compatível, que é muito complicado para você poder salvar no banco de dados. Pensando aqui no caso de um CPF, poderia criar uma chave primária com ele no banco? Sim, eu posso criar uma chave primária, vai ser ali uma string. Mas isso de fato vai trazer performance? Vai ser bom para o meu banco de dados? Não. Normalmente nós temos outros tipos de valores, outros tipos de fato vai trazer performance? Vai ser bom para o meu banco de dados? Não. Normalmente nós temos outros tipos de valores, outros tipos de campos que vão trazer mais performance. Então não significa que eu tenha aqui uma identidade CPF que lá no meu banco de dados eu não possa criar uma chave primária que seja um inteiro. Eu posso. Espera aí, então. Então, na minha entidade, vai ser o CPS, e lá no banco de dados é o ID, sim. Inclusive, eu posso trazer ele para cá. Tem, inclusive, esse conceito explicado pelo Val Guvernon no Redbook, que é o ID substituto, eu posso ter esse ID lá, porque é conveniente, porque é performático, porque vai me ajudar, inclusive pode ser algum, qualquer tipo, não precisa ser inteiro. Mas a questão é que o CPF precisa ser único, então ele vai acabar se transformando numa chave única, lá numa restrição de necessidade no banco, porque aí eu não consigo duplicar. Mas aí, na hora que eu for buscar essa pessoa, eu poderia buscar pelo ID? Sim, o ID ele pode ajudar em muitas situações, mas a gente vai buscar também pelo CPF. Faz sentido buscar pelo CPF porque o banco de dados ali consegue fazer indexação e tal, vai ser ágil. E aí entra o ponto da gente continuar usando o DDD no meio do projeto, porque na hora que você vai falar lá com o expert do domínio, você não vai falar do ID. O ID não é a identidade na entidade com o expert do domínio, você não vai falar do ID. O ID não é a identidade na entidade do DDD. Ela não faz parte da nossa linguagem ubiqua quando a gente for conversar. Quando você for falar assim, a gente precisa identificar a pessoa, você vai se referir ao CPF. Se você começa a falar ID, isso cria ruídos, desentendimentos, e você achando que você tem que falar o ID porque funciona lá por debaixo dos panos o ID. Não. Não foi estabelecido isso. Todo mundo tem que falar a mesma língua, tá? Então, o ponto crucial dessa entidade é justamente estabelecer a identidade. Se eu tiver uma pessoa aqui que tem CPF, que tem ID, o ID é o próprio... a identidade dela é o próprio CPF, mas vamos supor que eu tenha peso aqui, data de nascimento, nome, etc. Tem algumas informações que ao longo do tempo elas podem mudar. Data de nascimento também não vai ser uma informação que vai ser alterada. Mas nome e peso, sim. O Luiz, que tem outro nome, mudei para o nome XPTO daqui a 20 anos e meu peso também é diferente. E se Luiz de 20 anos à frente é diferente do Luiz de hoje, que eu posso ter registros de coisas que eu fui fazendo no sistema, quando eu for comparar, não, eu não sou diferente. As minhas características são diferentes, mas a minha identidade é a mesma. Fala de bola, pessoal. Então, nós temos aqui essa visão sobre entidades. Essa aqui é a primeira visão que a gente tem que ter. Na próxima aula, nós vamos falar sobre como tornar esse modelo rico, expressivo, com as regras de negócio. Então, vamos seguindo a nossa saga. É isso aí. E até a próxima.