Salve, beleza? Continuamos a saga aqui no Domain Dream Design. Agora vamos ver aqui o restante dos repositórios que nós deveríamos criar. Eu já trouxe essa implementação aqui, a gente vai discutir os pontos relevantes. Então vamos ver primeiro as interfaces. Eu acrescentei também uma interface para o repositório de Customer. Não tem nenhuma mudança, Na verdade, acho que eu estava até brincando aqui com alguma coisa. Isso aqui não é necessário. Eu posso remover. Ela vai ser igualzinha a de Partner. E a do evento é a mesma coisa. E quando a gente olha aqui para a questão do evento, tem event session e event spot. Não tem repositório para ele, somente para o evento. Uma coisa que eu fiz em relação à última aula, que eu tinha colocado partner, era aqui ponto nas interfaces, ponto repositório, ponto repository, ponto interface, eu mudei para traço, porque o ponto a gente usa uma vez só, nesse estilo de nomeação aqui, acho que eu não comentei, mas estou utilizando o estilo kebab case, que é tudo minúsculo. Então teve essa mudancinha, e eu usei para os outros também. Vamos ver o repositório de... Deixa eu tirar esse método aqui, que é outra coisa que eu estava brincando. Não muda nada em relação ao de partner, é a mesma ideia. Por isso que a gente poderia ter, eu até não vou criar aqui, mas seria simples de criar um repositório abstrato que você já tem esses métodos aqui pronto, passa ali só quando é necessário passar a classe, define lá um método para poder definir a classe e pronto. Não precisa ficar sendo repetitivo. Você só estende dessa classe abstrata e já está com tudo pronto. E o que é interessante, quando a gente olha para o caso do evento, a gente fala assim, poxa, o evento tem várias sessões, tem vários lugares e o repositório é a mesma coisa, porque esses frameworks que trabalham com o mapeamento, com o data mapper ali, eles tendem a fazer o salvamento de uma vez só. Então não muda nada. A gente vai passar o evento com o que tiver ali dentro, vai ser o persist aqui, ele vai salvar tudo numa transação. Então isso que é legal. Se eu tivesse aqui um RM que não trabalhasse com o Data Mapper e nem o Nurture of Work ali, a gente acabaria lá fazendo o mapeador e tem que fazer algumas coisas aqui, às vezes até algumas carries a mais para poder fazer a consulta. Então, na hora que você, no caso, eu estou falando de carregar o agregado, na hora de persistir até aqui que tem que ser feito também, às vezes tem que ser mais etapas. Primeiro tem que salvar o evento, depois tem que salvar os event sessions, depois tem que salvar os spots. Então não tem mudança nenhuma, mas a gente vai ter mudança no mapeamento ali relacional. Então tem que se criar os tipos para tudo que a gente quer documentar. Então, aquele CPF lá do Customer tem que também ter o objeto de valor aqui. Se eu for converter para o banco de dados, pego o value dele. Caso contrário, às vezes eu estou relacionando ele com o CPF, pode ser nulo. Ele vai puxar o nulo. Quando eu vou converter de volta, então converto para o objeto de valor novamente, e o tipo lá do MySQL que eu estou utilizando é o varchar11. Aí nós temos o id do customer, o VARCHAR36 e os IDs dos três eventos, o Event ID, o Event Section ID e o Event Spot ID. Todos com o VARCHAR36 na mesma esquema. Também daria para a gente poder fazer uma abstração. E agora, o que é mais detalhado aqui que a gente tem que prestar atenção é no esquema mesmo. No caso do Customer, a diferença vai estar que a gente não tem essa chave natural do nosso Customer, que é o CPF. Então, esse CPF tem que ser único no banco de dados. Então, declara-se ele a unicidade, ele vai gerar essa chave lá no banco. Para o campo, eu passo o custom type também para sempre lidar corretamente com o objeto de valor. Já no caso dos eventos, a gente coloca ele em todos os campos. Então, tem o id com campo personalizado, que foi criado para ele, o nome, que é um string 255 de tamanho, o description, que é um texto, pode ser qualquer tipo de tamanho, a data, que vai ser uma data. Se ele está publicado ou não, coloquei false aqui somente para poder forçar que é mais uma segurança, o total de spots começa com zero, os spots reservados também começam com zero. E aqui vem os relacionamentos. A gente já tinha visto o relacionamento aqui? Ainda não. Esse aqui é o primeiro relacionamento, essa aqui é a forma do micro-rm de fazer a relação. Então, se eu quero fazer uma relação com sections, eu coloco que ele vai ser 1 para muitos, 1, 2 pontos m, a anotação dele. Qual é a entidade referência? Então, aqui eu estou passando a nossa entidade rica como referência. E qual é o mapeamento do lado contrário? Porque a gente faz o mapeamento nos dois lados, que isso é algo convencional em URMs. E falo qual é o campo que está mapeando lá que o evento id que a gente não vai manipular ele na nossa entidade tá então aqui ó no session a gente vai ter lá o evento id que é o contrário o main to one então vai gerar chave estrangeira apontando pra evento e aqui vem duas informações relevantes para o microRM, que você tem que ver como você implementaria ela no seu devido RMI. Eu quero que, quando eu for lidar com esse campo, ele não recupere esse campo, não significa que na hora que eu for carregar, ele não vai trazer, ele até vai. Mas em alguns momentos, eu quero que esse campo fique omitido até mesmo para não ter nenhuma dificuldade para poder mexer com a entidade. Mas quando a gente consultar, ele vai acabar vindo. Mas em momentos, por exemplo, se eu usar o Entity Manager para poder fazer ali a criação, ele vai omitir esse campo aqui. Então, é de prática que a gente deixa isso como omitido aqui para... Olha, isso aqui não é importante para a gente. Se eu não coloco esse map to primary key, o que vai acontecer? Ele vai trazer esse evento e vai trazê-lo hidratado. Eu não quero. No máximo aqui, já que ele não tem como tirar, tem que fazer o mapeamento, eu quero que ele só traga o valor ali da chave, que vai ser o próprio UID. E aqui vem a chave, ou melhor, vem o tipo personalizado. Perceba que eu coloquei em todos os tipos personalizados, será que eu não importei isso aqui, correto? Que eu vou ver ID, esquema. Por que que eu não... não consegui ir aqui pra definição, agora foi. Perceba que eu coloquei aqui um comentário, tá? Que ele não funciona, esse Convert to JS value não funciona em relacionamentos. Então, esse tipo aqui é importante para a chave primária, quando a gente tiver a chave estrangeira vai ser usado também, mas quando ele vir, ele vai vir com o valor string, e aquela configuração que a gente fez no evento, vamos pegar aqui o evento Entity TS. Aqui, por exemplo, o caso do caso do event ID, não tem, a gente não está manipulando ele ali na nossa entidade, mas para o caso do partner, vai ser a mesma situação, isso aqui não é o microRM não usa para relacionamento que ele tem um modo dele de lidar ou com a chave estrangeira ou carregando a entidade alvo então por isso que a gente faz aquela verificação olha aqui no construtor recebendo objetos de valor partner id tá então armazeno ele. Caso contrário, eu gero com o objeto de valor. Então isso aqui serve também como uma facilidade que a gente criou lá atrás, mas também para contornar essa questão do ORM. Então sempre que tiver relacionamento, você tiver ali a sua entidade, faça aquilo ali. Receba o aceite, rece receber o valor puro também. Isso depende do seu RM. Você tem que ver como que lida. Mas é um cuidado que a gente tem que ter. Então, está aqui o relacionamento one to many e many to one. E para que a gente consiga montar esse objeto na íntegra, isso aqui é importante. Nós temos duas formas de fazer o carregamento em ORMs de uma forma geral. O Egger, que é o prematuro, e o Lazy, que é o retardado, de você estar retardando o carregamento dos relacionados. O agregado tem que ser retornado pela entidade já completo com todos os dados. Então, eu faço um EGA. Tem uma discussão que a gente poderia fazer um carregamento retardado para utilizar menos memória. Isso entraria em questões de políticas de otimizações, dependendo do agregado que a gente tem. Mas, de forma geral, eu quero carregar os dadosações, dependendo do agregado que a gente tem. Mas, de forma geral, eu quero carregar os dados para retornar o agregado na forma que ele deveria estar. Então, relacionamentos sempre, você vai, esses relacionamentos, não só o one-to-many, mas se você tiver um relacionamento do seu agregado com outra entidade, é sempre Egger para fazer esse carregamento. Então, nesse caso aqui, ele vai... Ele deu relacionamento do lado contrário. Eu já quero que ele seja carregado. Coloque também uma política da cascata em relação a três coisas que a gente pode fazer, que é o persist, o update e a exclusão. Isso aqui tem a ver com isso. Qual a política que a gente quer quando essa entidade, o evento, seja excluído e o que vai ter de impacto nos relacionados? Aqui eu quero que tenha impacto total. Se eu faço o persist, então eu quero que ele já crie tudo para mim. Ele vai entender que ele tem que criar tudo. Se faz o update, também ele vai forçar. Se eu faço a exclusão, ele vai excluir tudo. Isso aí depende de como você quer lidar com esse registro. Mas em ORMs com DataMapper, o cascade, ele vai te dar um poder ali sobre todos os objetos como que você vai manuseá-los. No caso do evento, a sessão do evento, é a mesma coisa, tem relacionamento ali com o Event ID que a gente já viu, e com os spots. O One to Many também, e aqui o Many to One, que é o lado contrário, que é ali o event session ID. Então, esse cara também vai ser carregado como... Inclusive, esse nullable aqui não tem... Acho que eu deixei como lixo aqui. Ele vai ser carregado como o UUID mesmo, por ali. ele vai ficar dentro da entidade, mas a gente não vai se importar com ele. Aí tem o mapeamento aqui do tipo personalizado, do Event Session ID. Então, tudo isso aí vai ficar no código para vocês poderem dar uma olhada que é basicamente, é só algumas configurações a mais do que a gente já viu. Na próxima aula, a gente dá uma brincada testando aqui essas persistências todas pra ver se está tudo funcionando. Então, pessoal, vamos seguir na nossa saga. É isso aí. E até a próxima.