Salve, Deus, beleza? Continuamos a saga aqui no Domain Dream Design. Agora, nós vamos modelar a parte mais importante aqui das nossas entidades. Na verdade, a order, segundo a nossa modelagem lá, é a mais importante. Mas sem os eventos, nós não conseguimos fazer nada. Então, eu já criei aqui algumas entidades, segundo o padrão que nós já criamos. Então, nós vamos trabalhar com o partner, que é o nosso parceiro, o evento, a sessão do evento e o Event Spot, que é o lugar ali que nós vamos vender de fato. Começando pelo Partner. É a mesma coisa do Customer, inclusive até mais simples, porque eu não quero colocar outras informações aqui. É óbvio que no ambiente real teria-se mais informações, mas eu tenho que ter esse Partner, porque todo evento está relacionado com um parceiro. Então, essa entidade tem ali o Partner ID, que é também um UID. Sempre a gente vai trabalhar dessa forma. Não temos um outro ID candidato, talvez poderia ser um documento. A identidade desse agregado poderia ser um CNPJ, ou algum campo que identificasse tanto oPJ, CPF, enfim. Poderia ser algo nesse sentido. Nesse caso aqui, então, a gente não tem candidato. Isso acontece muito em modelagem de domínio. Deixa ali o ID que você já está organizando para as suas outras entidades. Tem o comando de criar, tudo semelhante ao nosso custom. Agora vamos para o nosso agregado de eventos. Veja o seguinte, que nós temos event como o aggregate root, o event session como entidade, o event spot como entidade também. É a primeira vez que a gente tem um agregado nesse nível. Portanto, nós temos aqui o evento como agregado. Teremos as seções. Então, posso ter lá a sessão básica. Camarote. Ou poderia enumerar sessões também. VIP, enfim. E aqui eu tenho o preço. É aqui que eu estou colocando o preço, porque eu estou vendendo a sessão. E dentro de cada sessão tem os lugares então nós podemos colocar aqui algumas informações tipo a tá reservado outras informações ali referente ao lugar como o localização do lugar, enfim. Então, o agregado de evento contempla tudo isso aqui. Veja que a relação dele com as outras duas entidades é uma relação para muitos, porque nós vamos ter muitas sessões, no mínimo uma, e muitos lugares. Então, é um agregado, de certa forma, que tem uma certa complexidade, que é legal para entender como a gente tem que trabalhar com o DDD. E aquela história que eu já venho falando, a gente fica muito preso aos ORMs, fica viciado, e a gente perde a essência da programação, que é, de fato, criar a nossa lógica de negócio. Então, vamos entender aqui os dados que nós temos para evento, sessão e event spot. Para o nosso evento, aqui no construtor, ou melhor, no construtor é o que a gente vai passar, quero mostrar aqui. Melhor, no consultor que a gente vai passar. Quero mostrar aqui. Eu tenho o ID do evento, o nome dele, a descrição que pode ser nula, a data de realização desse evento, se ele está publicado ou não. Essa informação aqui pode ser relevante, porque às vezes eu queira desativar, estou acrescentando aqui uma lógica para dar um outro tom para esse agregado, posso querer desativar a venda ali em algum momento, estar publicado ou não muda também aquele primeiro momento que eu estou criando o evento. Eu posso ir fazendo as configurações, ir acertando as coisas, mas enquanto ele não estiver publicado, ele não vai aparecer lá para a venda. Então, é uma informação importante para controlar isso. Temos também o Total Spots e o Total Spots Reserved. Isso aqui é justamente para que a gente possa controlar, saber ali o total de lugares. E o total de lugares reservado. Então, os parceiros vão acompanhando esse valor, a gente coloca ele dentro do próprio agregado. Então, olha o desafio que a gente tem. Eu quero consolidar já esse valor sempre e armazenar no banco de dados. Uma outra estratégia seria sempre que a gente processasse isso em tempo de execução. Mas, claro, que já ter isso aqui processado e gravado no banco de dados vai dar agilidade para só mostrar a informação. O desafio vai para toda vez que acontece ali uma venda ou que é adicionado novos spots, tem que mudar essa variável aqui. E a relação com o Partner ID? Então, aqui a gente vê a primeira vez que um agregado se relaciona com o outro na prática. Então, ele referencia o ID. A gente está falando daquela história que tem o ID natural do nosso domínio. E esse ID não é colocado aqui na relação, porque aqui a gente precisa já relacionar diretamente com o ID que vai ter lá no banco de dados. Então, tem influência, de certa forma, não o banco de dados em si, mas a gente precisa manter certa compatibilidade para não complicar a nossa vida. Imagina que a gente colocasse aqui um CNPJ. Aqui seria o partner. CNPJ. aqui seria o partner para NPJ que seria a identificação natural ali eu não vou ter isso lá no banco de dados então toda vez que eu for persistir isso aqui, eu vou ter que converter de NPJ para ID tá então não vale a pena isso aí já CNPJ para ID. Então, não vale a pena. Isso aí já é uma piração que a gente pode ter que não faz sentido nenhum. Então, o UUID normaliza, por isso que é bom usar algum ID que pode ser armazenado em qualquer banco de dados, porque a gente não tem esse problema aqui. Inclusive, deixa eu até tirar essa parte aqui, que tem questão de sessão. Então, eu tenho o relacionamento aqui com o Partner ID. E no construtor, eu recebo todas as informações também. Então, o ID não é obrigatório. Tenho ali todas as informações e passo elas para cá. O que há de novo aqui nesse construtor é que no caso do Partner ID, eu estou recebendo aqui, estou abrindo a brecha para poder ser recebido, uma string. Eu posso tanto passar ele como string, como já o objeto de valor, e se eu passar como string, eu crio. De qualquer forma, se eu passar um valor qualquer aqui, como ele é um UID, vai ser validado. A gente tem a segurança que não vai ter um UID incorreto. Na criação, vamos pensar assim, estou criando, acabando de criar um evento. A gente não vai consolidar agora a sessão, nós não vamos consolidar outras coisas. Então, eu quero apenas... Aqui eu criei um tipo... Comando. Quando a gente tem um comando mais complexo, eu crio um type, ou pelo menos crio um tipo personalizado para ele, para poder deixar claro as tipagens não ficarem grandes. Também cuidado com outras linguagens de programação, para você não colocar muitos parâmetros e ser muito difícil, eu prefiro até criar uma classe se for necessário. A gente recebeu o nome, a descrição, a data e o partner ID. O restante das informações, o que vai acontecer? Não vai estar publicado, total de spots é zero, e o total de spots reservados também é zero. Beleza? Então, eu inicio ali aquele objeto, e já estou pronto para trabalhar. Inclusive, aqui eu posso colocar as outras informações no meu tool JSON. Está publicado o total de spots, total de spots reservado. Acho que estão todas aqui, porque depois do depois do spot reservado tem um partner ID. Show de bola. Já na questão da sessão, então nós temos também a mesma lógica de ID e etc. Então, ele é uma entidade filha da sessão. Ou melhor, é uma entidade filha do evento.ão, ou melhor, é uma entidade filha do evento. Ele vai ter o ID, o nome, a descrição também ali da sessão, se está publicado ou não. Então, olha só, eu tenho a visualização se o evento está publicado, mas eu posso ter uma sessão que eu quero desativar e eu não posso vender em nenhum lugar daquela sessão. Então, essa informação vai servir para isso. Dentro da sessão eu tenho o total de spots daquela sessão e o total reservado. E o preço. Então na hora de criar aqui a sessão, eu passo o nome, a descrição, o total de spots, isso aqui vai ser interessante porque isso aqui vai causar a criação dos spots e o preço. Então, a princípio eu passo essas informações, a descrição que está sendo passada ali, eu quero sempre forçar que ela seja null, que ela não fique undefined. Então, utilizamos ali o operador null colors, não vai estar publicada e é zero reservados. E a princípio aqui, eu não vou trabalhar com o total spots, porque a gente vai ter mais uma lógica aqui para lidar com esses spots. No construtor, a mesma lógica que a gente está acostumado. Inicia ali o id e inicia os outros campos. E aqui está o 2JSON com todas as informações. Já no caso do spot, é mais simples. Nós vamos ter o id do spot também é um new id. Então, as entidades possuem um ID. Mas tem até uma referência nos livros que o Vernon fala que, às vezes, uma entidade filha, você não tem uma necessidade de ficar fazendo uma identificação única para ela. Pode ser até, às vezes, uma identificação com um número inteiro, porque, às vezes, quando você vai persistir novamente, você pode querer destruir o que estava lá no banco de dados e refazer novamente. Então, a entidade em si, às vezes, você não precisa de ter um UUID para ela. Tem um ID ali só para poder fazer alguma identificação e às vezes ele nem é tão importante dentro do agregado. Mas eu tenho o id o location que é justamente ali alguma informação referente à localização se ele está reservado ou não ou se ele está publicado ou não que às vezes eu posso querer publicar um spot por algum motivo para poder reservar ele mais tarde para alguém ou que aconteceu algum problema com aquele lugar eu não posso reservar mais esse cara. Então, beleza, o construtor, a mesma história, inicia as informações. Na hora de criar, veja que eu preferi passar um create sem nenhum comando. Na verdade, a gente até poderia tentar determinar um location de forma aleatória aqui, mas eu quero que essa operação gere o spot e isso venha como consequência depois. Inclusive, deixa eu até tirar umas coisas aqui que a gente vai fazer juntos. Eu não quero me preocupar com isso aqui agora. Eu estou criando o spot, o location é nu, não está publicado e não está reservado. Então, o que a gente tem que se atentar sempre nessa operação de criação, que faz sentido ali, às vezes, não criar, colocar toda a lógica. A gente fica com esse pensamento de ORM, eu não vou criar, eu tenho que passar todas as informações, não necessariamente. Nós podemos dividir determinadas operações aqui em outros métodos. Eu tenho a criação ali que faz sentido para poder gerar aquela instância, para poder iniciá-la. E depois outros métodos para poder operacionalizar com essas informações que podem ser reusáveis também no momento que eu vou atualizar essa entidade. A gente vai ver como que a nossa mente fica vacinada com RMs e na hora que a gente está trabalhando com o DDD, a gente volta à essência da programação. Então, esse aqui é o nosso desafio, pessoal. Lidar com esses três e tem o partner aqui envolvido que a gente tem que passar ele com os nossos eventos. Então, o nosso desafio agora é criar as operações dos nossos na verdade, do nosso agregado de eventos. Então, é isso aí e até a próxima.