Salve, Deus, beleza? Continuando nossa saga aqui no Domain Dream Design, continuando essas operações que nós temos que fazer nos nossos agregados, agora eu vou mostrar uma operação que não é muito simples, mas que vai explodir a sua cabeça em relação ao entendimento do domínio. Quando a gente olha para o evento, quem vai criar o evento? evento, quem que vai criar o evento? Pode até ser que o administrador do sistema faça a criação do evento pelo parceiro, mas a gente entende que o parceiro é que vai ser responsável por criar o evento, de consolidar todas as informações. Então, por que não? Como o nosso evento depende aqui do ID de Partner, e a gente está falando, parceiro cria o evento. Preste atenção nisso. Por que não, dentro de Partner, a gente ter um método para poder gerar um evento. Como assim? Vamos fazer? Eu vou criar aqui um initEvent. Nós vamos receber aqui algumas informações. Então, isso aqui também. Como é que eu posso chamar isso aqui? Vou colocar isso aqui De comando A gente não tem muitas informações aqui Mas até é bom colocar aqui em cima Um export type Init um export type, init, event command, o scope pilot já preenche rápido aqui para mim, pronto. Eu preciso só dessas três informações, posso colocar aqui o meu init command, certo? Então, veja que eu não preciso receber o ID do parceiro, porque eu já tenho. Então, eu vou retornar um event.create, passando o meu comando e o partner ID, que é o meu próprio ID. Olha só o que eu acabei de fazer. Se eu chegar aqui agora num teste de Partner, deve criar... Vamos colocar um deve criar um evento aqui também, porque é o nosso objetivo vamos fazer um partner.create antes, porque eu tenho que ter um partner eu tenho aqui o parceiro, não tem mais nada ele é bem simples tira o restante aqui das coisas. E agora, o bom é que o Copar já entende a pegada. Eu preciso passar o nome do evento, a descrição e a data. Show de bola, vai criar o evento. Então, aqui no meio do nosso código, eu tenho parceiro criando o evento e até escondendo ali a questão do ID, já embutindo diretamente. Não fica fácil de criar o evento dessa forma? Essa operação dessa forma aqui, ela pode ser usada ali no nível de aplicação, porque, de qualquer forma, eu tenho que ter o ID do partner, ele veria talvez da autenticação, mas seria interessante que eu consultasse se ele existe, importante, não poderia fazer a operação sem ele existir, então posso delegar essa operação para ele. Então, ele conhece os detalhes, o parceiro conhece os detalhes de criar. Isso está transcrito. Isso aqui é poesia pura. Não é um devaneio, não. Isso é mostrado nos livros de DDD. Quando você começa a perceber que a gente... Poxa, com RMs lá, eu não tenho essa relação rica entre os objetos. E a gente começa a fazer ela com o próprio DDD. Então, fizemos mais uma operação. Depois a gente vai acabar utilizando ela. Sobre a questão aqui de mudar, por exemplo, fazendo um update. A gente fica pensando lá na atualização dos dados de uma entidade. Ah, eu tenho que criar aqui nesse caso um update aqui para os dados de parceiro. A gente está pensando em nível de banco de dados. Você tem que criar as operações conforme que faz sentido para o negócio. A gente tem ID, que não vai mudar, do parceiro e o nome. Então, o update é algo anêmico. O que está acontecendo nesse update? É só colocar as informações, a gente não sabe o sentido dessa operação. Então, você pode justamente criar um change name que recebe o nome e muda esse nome. Ah, mas esse change name é um set name convencional que a gente está acostumado a fazer. Não, não é. Porque o change name é uma operação de negócio que aqui eu nem estou colocando o comando, porque é apenas um campo só, posso passar ele diretamente, não preciso sempre passar aqui o comando dessa forma. O change name pode fazer outras questões, inclusive disparar ou registrar um evento. A gente vai chegar nessa parte depois. Um set name que eu poderia ter aqui, não tem nenhum problema de você criar ele na sua linguagem, ele vai apenas mudar o valor. Operação de negócio envolve você fazer as transformações, disparar evento e algumas outras questões também. Então, quando às vezes você não tem o refinamento do domínio, você não está expert ali, faça essas operações. É estranho fazer assim, mas fazendo dessa forma, depois você combina lá na sua camada de aplicação. Tem patroles até para você não ficar fazendo if, se foi passado, se foi passado. Porque você pega lá, tipo, você tem uma operação de update em nível de aplicação. Aí você recebe aqui vários dados. Esses dados não precisam ser obrigatórios, porque o usuário não precisa passar tudo. Aí você fica fazendo assim, if name, aí passa um partner change name. Você começa a espalhar isso no meio do seu código. Tem maneiras da gente melhorar isso aí. Mas isso aqui é muito melhor do que ter um update que não demonstra expressividade. Eu posso ter também um change description? Sim, eu posso ter. Então, vamos criar aqui dentro do... Eu vou ter um change name um change description tem alguma outra informação que eu tenho que modificar? eu quero modificar aqui a data, posso mudar a data também. As operações todas são combinadas. A princípio, a gente não tem uma regra de negócio que é o update. Não, isso aqui são as regras de negócio. Eu posso mudar o name, posso mudar a descrição, posso mudar a data. Às vezes, eu posso ter uma operação só que é mudar a data o problema de você criar o update e ficar passando muitas informações além de não ser expressivo aí agora eu preciso passar somente a data, então eu tenho que permitir que os campos os outros campos sejam opcionais e aí você começa a tornar isso aqui muito complexo beleza, então eu posso fazer essa operação também para a sessão. Então, eu posso ter aqui os changes. Eu não tenho ainda uma maturidade para poder analisar se tem que fazer alguma operação agregada. Então, a gente faz os changes para cada campo. Mas o que vale mais levar em consideração aqui é a mudança de preço. Pelo menos isso aqui a gente teria que ter, porque o preço da sessão ali pode ser alterado. E isso aqui poderia levar a gente a fazer algum outro tipo de processamento. Beleza. Já no Spot, nós podemos trabalhar com o Change Location, que seria a única operação a princípio aqui, bem simples. A gente fazer. Então, estão aqui as operações. Agora, pensando no nível de eventos novamente, a gente poderia ter de uma regra de negócio o que fosse interessante para poder lidar com essa lógica de ativar o evento ou não. Nós temos o isPublished, que controla se o evento está publicado ou não, permitindo que eu desative o evento de ser mostrado lá na minha área de vendas ou até de conseguir comprar nesse evento. Então, eu poderia ter simplesmente aqui uma outra operação. Essa aqui eu poderia colocar... Eu vou colocar ali em cima então eu tenho eu não tenho aqui um set eu tenho isso aqui pode também acarretar a outros processamentos a trabalhar com eventos a gente vai olhar isso mais tarde como eu já falei então eu posso também replicar isso aqui, essa operação para a sessão. Eu posso publicar a sessão ou despublicá-la. Então, eu poderia até fazer um unpublish também. Ah, eu não quero publicar, quero despublicar o evento. Então o evento inteiro não vai aparecer. Ah, eu quero despublicar a minha sessão? Então, beleza. Somente aquela sessão ali que não está ativa. Também eu posso fazer essas mesmas operações aqui no meu spot eu posso ativar ele ou não ativar mas pensando numa operação que a princípio, eu estou criando tudo desativado, a minha sessão está desativada, os meus spots que estão sendo gerados. Posso gerar 10 mil de uma vez, todos vão ser desativados, e o meu evento também está desativado. Então, eu poderia ter uma regra de negócio para ativar todo mundo. Então, a gente vai fazer aqui a festa agora. Primeira coisa, eu poderia chamar... Inclusive, até pegando a dica do Uncle Bob, lá do Clean Code, vamos colocar o Publish All, porque ele vai usar o próprio Publish aqui. o Publish All, porque ele vai usar o próprio Publish aqui. Então eu vou publicar o meu evento e vou chamar cada um das sessões e fazer o Publish nele. Porém, eu poderia se eu chamar somente o Publish, eu estou mudando somente o Publish da sessão, não estou mudando dos spots. Nós poderíamos ter também um Publish All da sessão não estão mudando dos spots. Nós poderíamos ter também um publish all. Então, eu tenho que primeiro publicar a sessão. Chamo cada spot e chamo publish. Então, aqui dentro do evento, eu chamo publish all. Pronto. Olha a regra de negócio nessa. Eu sei quando isso aqui vai transformar todo mundo. Independente se esteja ativado ou não ativado, ele vai fazer a mudança em todo mundo. Eu poderia também despublicar todo mundo, mas essa ação eu vou deixar como dever de casa para vocês. Vamos pegar aqui o nosso teste. A gente estava brincando aqui. Vamos colocar aqui o teste. Deve publicar todos os itens do evento. Então, você vai ver que ele gera aqui para a gente um exemplo. Olha o Copilot processando aqui. Ele não vai gerar, então a gente faz essa replicação aqui. Então, eu tenho uma sessção, vamos até criar duas. Eu tenho a seção aqui número 2. Uma descrição qualquer. O bom que o Compile, eu queria que ele me ajudasse aqui para descrição da sessão 2 e aqui também vai ter que eu vou colocar mil spots ao preço, se eu tenho de mercado, se eu tenho muitos por um preço um pouco menor. Então o que eu vou acabar fazendo aqui, um publish all, a gente sabe que tudo isso aqui foi criado com o false, então agora nós temos que verificar se nós esperamos que o evento seja o Published seja True. Vamos pegar, vamos salvar isso aqui para ver se deu certo, já deu certo. Ficou verdinho lá, agora vamos pegar, vamos salvar isso aqui para ver se deu certo, já deu certo, ficou verdinho lá, agora vamos pegar a seção eventSection.values, e aí vem a mesma coisa continuou verdinho lá, vou só executar aqui pra ver se tá ok, então deu certo, agora pra cada spot que eu tiver, a gente não sabe quantos spots podem ter. Então, eu vou pegar section.spots4eating. Ele já pegou o espírito aqui. Eu quero verificar se cada um... Na verdade, aqui eu teria a seção 1 e a seção 2, né? Porque eu criei as duas seções. Então, a seção 1 tem que estar publicada a sessão 2 também então para a sessão a gente pode até fazer aqui um bem bolado de sessão um spots e section dois spots pego todo mundo ali e verifico se está ok o que está faltando aqui? um parêntese com um ponto e vírgula vamos executar show de bola então agora eu tenho um método para poder fazer toda essa publicação vamos imaginar em nível agora de interface que teria lá um momento que eu publico tudo. Então veja que até o momento a gente não pensou em banco de dados. Banco de dados é muito importante, a gente vai ver isso daqui a pouco, mas a gente só está se preocupando aqui com as regras de negócio em si. E outras regras podem ser agregadas. Eu posso ter métodos aqui para poder verificar se o assento está disponível. Tudo parte, tá? Tudo parte sempre pelo agregado. Todas as regras de negócio internas aqui, elas não vão ser acessíveis diretamente. Sempre o agregado controla. Ele protege a consistência disso tudo. E depois nós vamos salvar ou atualizar lá no banco de dados. No decorrer das aulas, a gente acaba criando outras regras de negócio, mas eu acredito que isso aqui seja suficiente para a gente poder pegar o espírito do DDD. Então, o DDD remete àquilo que a gente aprendeu lá atrás. Lembra quando você ficava programando sem utilizar biblioteca, sem ficar pensando em banco de dados? Você pensava, de fato, nas regras de negócio? Pois é. Então, a gente tem que recuperar essa época da nossa vida, porque o RMS, de fato, a gente fica muito preso à forma dele de trabalhar. Não estou querendo demonizar esses caras, eles nos ajudam a salvar as nossas coisas no banco de dados. Mas a gente meio que vai sempre, a gente pauta as nossas regras de negócio baseado na forma deles de trabalhar, perdendo, de fato, essa riqueza que nós temos nessas operações aqui. Então, pessoal, vamos seguindo a nossa saga. É isso aí. E até a próxima.