Salve, Deus, beleza? Continuando a nossa saga aqui no domínio do RuneDesign, agora a coisa vai ficar muito mais interessante do que a gente já fez ainda nesse módulo pessoal. Eu acredito que esse módulo de DDD que tenha aberto a sua cabeça em relação ao desenvolvimento de software é uma visão muito diferente do que a gente normalmente está acostumado a desenvolver, justamente por conta que a gente fica muito preso a framework, a tecnologia. E esse módulo aqui, ele vai fazer um boom ainda mais na sua cabeça. Quando a gente começa a trabalhar com os eventos de domínio, como o próprio Val Guvernon fala lá no Redbook, ele fala o seguinte, quando você começa a trabalhar com eventos, você só se pergunta por que você não conheceu isso antes, você não vai querer trabalhar sem, porque os eventos abrem uma série de possibilidades aqui dentro do nosso projeto. A gente já falou disso lá na parte do design tático, mas eu posso registrar todo evento que acontece, isso vai me ajudar a fazer auditoria, eu posso fazer replay do histórico de tudo que está acontecendo, de todos os agregados, nós podemos comunicar com outros subdomínios, enfim. A gente tem uma série de benefícios ao trabalhar com esses eventos. Então, lembrando que esses eventos, eles são sempre disparados, ou no mínimo registrados, toda vez que acontece um comando dentro do nosso agregado. Então, onde que esses eventos poderiam ser disparados? Pegando o caso do evento. Ah, eu vou disparar um evento no create, não no construtor. Construtor é usado para a gente poder construir objeto, mas não necessariamente nós estamos trabalhando com esse conceito de criar, fazer a operação de criação. Porque isso aqui serve mais para a gente poder gerar o objeto, o ORM lá, fazer a geração dele como o micro ORM faz, e eu não tenho nenhum compromisso depois com fazer rastreabilidade desses eventos. Então, por isso que é interessante você ter ali um, nem que seja uma factory separada, normalmente criar dentro do próprio agregado fica bem fácil, então aqui a gente pode disparar um evento, change name, change description, change date, tudo isso aqui são comandos, que eles podem receber parâmetros ou não, todos eles podem registrar um evento. Não tem contraindicação. Você pode disparar eventos aqui para toda operação, ela gera um evento, ela vai gerar um evento sempre no passado. Mesmo que sejam aquelas operações simples, em parta, aqui também no Create tem um evento. Aqui no caso do InitEvent, o evento está dentro do próprio agregado. Um detalhe importante é que somente agregados que disparam ou registram eventos. Num caso aqui que eu tenha um event session e event spot que são entidades filhas, eles não disparam eventos. Por isso que a marcação de Android Guest Route vai nos ajudar a identificar. Muito bem, que eu sei que chegou aqui aqui e vou ter eventos sendo disparados. Inclusive, a gente vai até colocar isso dentro da nossa própria abstração. E aí, voltando àquele conceito lá do EventStorming, que a gente faz uma tempestade de eventos, que é justamente quando você começa a enxergar os eventos que precisam ser disparados e você consegue encontrar quem? Agregados, né? Especialmente agregados que disparam eventos. Então, é uma forma fácil de você ir se enriquecendo no domínio que você tem a ser construído. Então, nesse capítulo, nós vamos construir esses eventos aqui e depois a gente vai fazer uma integração também, porque esses eventos podem comunicar com outros contextos que podem estar em uma aplicação completamente diferente. Eu quero agregar aqui um Web Team Q para a gente poder ver como esse fluxo de eventos é trabalhado no final das contas. Então, pessoal, vamos para mais uma mini saga aqui no módulo. É isso aí. E até a próxima.