Salve, beleza? Continuar essa saga aqui no Domain Driven Design. Vamos ver agora um exemplo mais palpável, que vai deixar mais claro ainda, essa questão de criar um objeto de valor e também validar dados. Eu tenho um exemplo aqui de um CPF, justamente que é necessário no Customer. Então, vamos considerar que o CPF também seria um objeto de valor bem genérico, não seria apenas criado aqui em eventos. Então, eu vou criar um cpf.va.ts. Se eu tiver algum objeto de valor específico aqui de eventos, eu posso criar ele aqui mesmo. Então, está aqui o meu código de CPF. Então, tem a classe que estende de Object Value, inclusive eu tenho que fazer alguma importação aqui, não. Está tudo ok. Eu vou lidar apenas com uma string, inclusive aqui tem que ser obrigatório. Logo de cara, com o valor, já posso passar uma expressão regular ali para poder tirar qualquer coisa que não seja um dígito, que é essa expressão que está acontecendo aqui. E aí nesse método privado, até é bom que eu coloque privado para não ser público, não tem por que as pessoas verem que essa validação está acontecendo. Eu vou fazer todas as validações correspondentes de um CPF. Eu quero ver se ele tem 11 dígitos, que a gente tirou lá todos os pontos e traços. A gente tirou lá todos os pontos e traços. Também se ele não é tudo igual, porque tudo igual também não pode, se ele for dessa maneira aqui, está inválido. Porque a conta acaba dando certo com os dígitos verificadores. Então não existe CPF com os números tudo iguais. E aquela regrinha lá para poder fazer o cálculo dos dígitos verificadores. Mas sempre quando eu tenho uma invalidação, a gente estoura um erro. Para de fato ali já ter um comportamento que aconteceu alguma coisa de errado. E aqui embaixo está o erro do CPF. Então lá, o name eu não quero utilizar no caso, então eu vou deixar dessa forma aqui. Então, eu tenho que voltar aqui para string e aqui para string. Mas, o CPF tem que ser CPF e aqui também CPF e aqui também CPF e aqui também CPF e aqui também CPF. Tá? Show de bola. E aqui eu tiro o name. Mas ainda assim eu posso fazer uma melhoria, isso aqui também é uma dica de como que a gente pode administrar melhor essa relação das entidades com os objetos de valores. Eu recebo um cpf no create, e criar o cpf é algo tão simples que o próprio agregado, a própria entidade, pode ter esse conhecimento. E se aqui eu receber uma string, própria entidade, pode ter esse conhecimento. E se aqui eu receber uma string, e aí eu passo o name e crio já o objeto aqui. É bem melhor, porque isso torna o manuseio aqui do custom, inclusive deixa eu tirar isso aqui, né? Testes aqui malucos vamos criar uma pastinha de testes aqui no estilo JavaScript então eu tenho um customer.entity.spec.ts então o teste deve criar um cliente. Quando nós formos utilizar o nosso agregado, o create fica muito mais simples de você passar um nome e um cpf qualquer. E nesse caso aqui, o que vai acontecer? Quando eu rodar esse teste, ele vai lançar um erro, ele vai falar que o CPF é inválido. Ele tem os 11 dígitos, não são iguais, mas na hora do cálculo do dígito verificador, vai dar errado. Inclusive, vamos pegar aqui um CPF, deixa eu fazer aqui um gerador de CPF. Gerar um CPF qualquer. Esse não é o meu CPF. Não tente fazer fraude. Agora até deu certo aqui, né? Posso executar diretamente. Pronto, passou. Então, ele vai aceitar os dois formatos. Isso também já é legal, porque o meu objeto de valor já organiza, já aplica uma sanitização no meio dos dados. Então na hora de acessar aqui o meu Customer, que eu tiver que pegar o meu CPF, esse aqui é o objeto de valor. O valor está em value. Então, todo objeto de valor que eu criar com essa lógica aqui, sempre eu acesso o value para poder mandar para o banco de dados ou para poder fazer algum processamento. E isso vai deixar bem claro. Quando eu ver esse value na frente, eu sei que o anterior é, de fato, um objeto de valor. Então, pessoal, vamos seguir na nossa saga. É isso aí e até