Salve, Deus, beleza? Continuando a nossa saga aqui no Domain Dreaming Design, vamos começar a criar a nossa primeira entidade aqui na aula. A mão, com certeza, está coçando para isso. Como eu já falei que tudo do domínio vai ficar dentro da pasta Domain, então eu vou criar a pasta Entities aqui, justamente porque nós podemos criar outras entidades. A pasta Entities vai ser para abrigar também agregados, porque a gente acaba, às vezes, se referindo aos próprios agregados como entidades. É o nome mais interessante da gente trabalhar. E aqui dentro, vamos criar a nossa primeira entidade, que é o customer.entity.ts. Essa forma de dar esse sufixo para o nome do arquivo é apenas uma maneira que eu gosto porque eu já estou acostumado a trabalhar com frameworks como o Angular, como o Nest. Então, colocar o que é ali faz com que fique mais fácil de identificar, de pesquisar na própria ideia. É apenas um detalhe de nomeação. Se eu encontrar outras linguagens de programação, você coloca isso aqui em maiúsculo e não coloca esse entity. Isso é apenas um detalhe da convenção da comunidade da própria linguagem. Então, eu vou exportar a minha classe Customer. Quem sabe que ela é um agregado? E o que é a primeira coisa que eu vou fazer aqui? É determinar os campos. Então, eu tenho um ID, e a gente vai acabar trabalhando com um UUID, depois a gente fala mais sobre isso, um CPF, que vai ser uma string também, CPF não pode ser número porque começa com um zero, e o nome do customer. Você talvez esteja se questionando do que eu falei lá atrás, que a gente tinha que encontrar uma identidade para a nossa entidade, para ela ser uma identidade. A gente falou lá do CPF. O CPF poderia ser a identidade da nossa entidade? Sim. Ele pode ser. Ele identifica o customer dos outros. Mas aí que entra a questão de a gente entender que o DDD especifica isso, mas agora a gente está na parte técnica. E nós não podemos desconsiderar a tecnologia de armazenamento. A gente vai trabalhar com banco de dados, certo? É interessante que a gente trabalhe com uma chave primária lá no banco de dados que seja uma string. Não tem problema nenhum a gente fazer, mas em relação à performance, em relação à indexação, em relação a ser mais eficiente para poder lidar com os registros de customer. Não convém a gente lidar com esse CPF como sendo a chave primária. Os bancos de dados preferem que você tenha ali um ID que seja um inteiro ou que seja um UID com um binário. A gente tem aqui, inclusive, vários formatos, mas depois a gente pode falar mais sobre isso. com um binário, a gente tem aqui inclusive vários formatos, mas depois a gente pode falar mais sobre isso posso armazenar lá um UID ordenável que já existe esses formatos, mas esse ID que está aqui em cima aqui, ele serve como uma outra identidade que é conveniente a gente criar aqui dentro, mas em momentos onde a gente necessita trabalhar com a recuperação desse customer criar aqui dentro, mas em momentos onde a gente necessita trabalhar com a recuperação desse customer, nós vamos trabalhar com o CPF, porque quando alguém fizer alguma coisa lá numa interface de usuário, provavelmente ele vai digitar para poder identificar a pessoa pelo quê? Pelo CPF dela. Então, o CPF aqui a gente fala que é uma identidade natural, e isso aqui é uma identidade substituta, que é conveniente para o banco de dados. Mas, quando a gente vai, obviamente, relacionar esse customer com outros, nós vamos acabar utilizando o ID, claro, porque ele que vai ser uma chave secundária, ou melhor, uma chave estrangeira em outras tabelas. Beleza. Então, eu tenho aqui esses três campos. O que eu vou fazer? Vou criar um construtor. No caso do JavaScript, eu não gosto muito de criar o construtor dessa forma, a não ser que eu tenha um campo só ou dois. Mas, com certeza, sempre a gente vai ter mais. Eu prefiro acabar criando um objeto E passar um objeto no construtor Porque é muito melhor Você fazer um new customer Passando um objeto com todas as informações Do que passando um customer Com vários parâmetros E às vezes não fica claro exatamente O que significa cada parâmetro Então nesse caso aqui, com TypeScript, nós podemos criar um typing, que eu vou chamar de Customer Constructor Props. Então, eu vou ter aqui o ID, o CPF e o nome. O Copilot está me ajudando a poder criar as informações ali. Então, aqui eu recebo já um objeto em que eu pego cada informação e vou fazendo atribuição para as variáveis. Beleza, fiz a atribuição aqui. Então, torna mais fácil para poder manusear, para poder testar e etc. Show de bola. Quando eu faço um new customer, estou aqui passando essas informações, isso aqui representaria a criação do Customer. É a operação de criação, estou gerando essa instância. Quando eu usar um repositório para poder salvar, poder criar, entenda a diferença. A operação de criar é feita na entidade, no agregado. O salvar tem a ver com a persistência. Então, isso aqui já representa toda a entidade, no mínimo, ela vai ter uma ação de criar, porque você vai ter que criar ela em algum momento. Mas aí que entra um pensamento que a gente tem que ter na frente, que nós vamos ter um banco de dados, alguma biblioteca ali que vai fazer o carregamento. É mais conveniente que eu faça aqui um método de criação para ele representar a criação e deixar que o construtor seja um cara que eu chamo ali para poder iniciar aquela instância, mas não necessariamente representou a operação de criar. Porque quando eu estou carregando ele do banco de dados, o RM lá da vida vai fazer apenas um mil. Isso aqui não representa, eu não estou fazendo a operação, estou apenas hidratando a classe para poder manipular ela depois. Então, eu gosto de fazer essa distinção aqui para poder deixar isso bem claro. Então, aqui no caso, eu vou chamar sempre, vai ficar fácil da gente ver as operações em cima de uma entidade. Eu vou chamar isso aqui de comando, que é um comando, lembra lá do Event Storming? A gente está fazendo um comando, que é um comando lembra lá do EventStorming? A gente está fazendo um comando em cima de um agregado? Então eu tenho o nome e tenho CPF. Por que eu não estou passando o ID aqui nesse caso? Porque quando eu estou criando o meu Customer, eu posso delegar uma lógica para já gerar esse UID que eu vou ter de forma padrão. Então, eu só passo aqui um return new customer, passando o meu comando. Isso significa que eu não sou obrigado a passar o ID, então aqui no meu construtor eu posso deixar o id como facultativo, que vai tirar o erro aqui do meu customer. Pronto. Então eu tenho a minha entidade criada com a primeira operação e a distinção dela do nosso construtor. E para finalizar a criação dessa entidade, é sempre bom que a gente tenha aqui algum método que a gente possa converter para string. Aí é bom para poder fazer o debug, porque ele pega todos esses dados aqui e, no caso do JavaScript, eu poderia fazer um string.ify passando a própria referência, ele vai mostrar lá o id, cpf, name. Mas eu prefiro fazer aqui um toJSON passando um retorno com um objeto simples, sem a referência da própria classe. Isso aqui serve até se a gente quiser serializá-lo depois, mas em outras linguagens de programação, a gente tem esses métodos padrões mágicos que você pode criar com base nas suas necessidades. Tem toString, tem até método para você poder fazer uma comparação entre uma entidade e outra. Como que a gente compara uma entidade a outra? Comparando apenas o ID. E normalmente esses métodos podem até ser uma abstração que a nossa entidade usa. A gente vai falar disso na próxima aula. Então, pessoal, vamos seguir na nossa saga. É isso aí. Até a próxima.