Salve Deus, beleza? Continuamos essa saga aqui no Domain Dream Design. Para a gente poder encerrar esse capítulo, eu queria falar sobre essa abordagem, que ela serve muito de apoio para que a gente coloque o DDD, tanto na prática com a visão estratégica ou com a visão tática. O EventStorming, tempestade de eventos, é criado por esse camaradinho aqui. Na verdade, é um workshop que é do Alberto Brandolini. E esse aqui é o site que você pode acessar, do eventstorming.com. Aqui tem algumas informações sobre o workshop, inclusive tem aqui o workshop para que você possa fazer a compra. Não necessariamente aconselho que você faça a compra do workshop, a não ser que você queira porque é um pouquinho salgado, mas você pode comprar o livro do Alberto Brandolini, tá? Ele tá aqui na LeanPub. Você pode pagar um mínimo de 9 dólares. O livro tem já um bom tempo que ele não é atualizado, não tenho ideia se ele terminou ou não, mas o que já tem aqui no livro já é suficiente para que você entenda essa forma de a gente modelar o nosso problema. O WebStorming nada mais é do que um monte de post-its, essas notinhas coloridas, que nós vamos utilizar ali para ter uma visão melhor do problema que vai ser estabelecido. Então, antes de tudo, isso, claro, se você puder, na verdade, no livro é estabelecido assim, mas a gente sabe que hoje muitas empresas funcionam totalmente home office, então não dá para a gente poder fazer justamente a ideia do Alberto. Mas se a gente estivesse no ambiente físico, pegaria-se lá gerente, PO, desenvolvedor, domain expert, todas as pessoas que estão envolvidas ali Principalmente o Domain Expert Se não tiver Domain Expert Tem necessidade de fazer isso Reúne-se todo mundo numa sala Tire as cadeiras Arraste as cadeiras ali para um canto Para todo mundo ficar em pé E aí, de preferência Que você tenha um quadro branco Ou se não, a sala ali Com as paredes brancas, e a gente vai começar a analisar os problemas que têm que ser resolvidos, o que o software tem que fazer, e isso vai acabar virando basicamente os eventos, e nós vamos vendo ali todo o fluxo que acontece. Mas dado que muitas vezes a gente não consegue fazer isso, desde que você tenha pelo menos ali um workshop, uma live acontecendo com todo mundo envolvido do software, pega qualquer lugar aí, abre um software qualquer, então você consegue fazer essa técnica também. Então, a ideia dela, na verdade, é que nós vamos descobrir os eventos que vão acontecer nesse software, e a partir desses eventos, vai ficando mais claro o que precisa ser construído. Na verdade, não só o que precisa ser construído no nível tático, mas a gente vai tendo uma ideia melhor dos contextos. E isso acaba fazendo aquele refinamento que a gente tem falado tanto aqui, que nós cada vez mais temos que ficar especialistas nesse domínio do problema que nós estamos fazendo. Então, eu tenho aqui o Inzico, depois eu compartilho com vocês essa... Como que chama isso aqui? Essa coisa toda do EventStorm que eu criei. Eu já tenho aqui os post-its que nós temos um significado para cada um deles e as cores que você deva usar, que não é obrigado a usar dessa forma, mas é apenas uma sugestão. Então, a gente vai ter um post-it para evento, outro para comando, um para alguma coisa que seja externa, as policies ali, que é algo que vai ser chamado quando algo acontecer, ou seja, quando um evento acontecer, os próprios agregados. Então, o EventStorm vai nos ajudar a identificar entidades, agregados. Às vezes é muito difícil. Vou idealizar agregados na minha cabeça? EventStorm ajuda nisso também. Temos os atores, que são esses post-its amarelos. Os hotspots são problemas que podem acontecer, novas oportunidades. E a arrow que é voltada para uma tomada de decisão, que são as ações que estão acontecendo. Então, dado aqui o nosso sistema, que nós temos cliente, parceiro, administrador, esses são os agentes do nosso sistema. Esses aqui são os eventos que, por enquanto, nós conseguimos idealizar. Eu tenho o evento de cliente criado, parceiro criado, evento criado, reserva realizada, ticket gerado, e e-mail enviado. Isso aqui são coisas que aconteceram, são coisas do passado. Quando você começa a identificar os eventos, é legal porque quem é o responsável por gerar eventos? Agregados. Os agregados que geram os eventos. Então, uma vez que eu tenha um evento de cliente criado, então, cliente é um agregado. Se eu tenho um parceiro criado, parceiro é um agregado. Se eu tenho um evento criado, evento é um agregado. Então, já é interessante porque a gente já sabe os agregados que têm que ser criados no sistema. Além disso, nós temos também os comandos. Comandos vão ser esses post-its azuis aqui, que estão do lado dos eventos. Então, aqui a gente já começa a ter uma visão das operações que tem que acontecer no software. O ator, que é o parceiro, ele vai executar um comando de criar evento, depois vai ser disparado o evento criado. O parceiro vai criar uma sessão no evento, isso aqui eu estou idealizando para um pensamento meu de como eu geraria aquele sistema, porque eu vou criar o evento que vai acontecer em uma determinada data. A gente tem muitas coisas para serem configuradas ali. A gente não vai configurar tudo de uma vez. E acontece que em um evento eu posso ter áreas. Posso ter a sessão 1, sessão 2, camarote, esse tipo de coisa. E aí ter um preço diferente para cada tipo de ingresso desse. Então, eu posso ter o parceiro com o comando de criar sessão do evento. Sessão do evento criada, inclusive esse evento até o não-luno. Coloquei ele aqui. Vou até replicar ele para cá também. Vou colocar aqui. Esse aqui é o da reserva. Está pequenininho para vocês, mas... Aqui, pronto. aqui pronto agora aqui nós temos um comportamento interessante sobre essa questão da sessão porque olha só disparei o comando de criar a sessão do evento sessão do evento. Sessão do evento criada, mas a gente já quer criar os spots. Porque aqui no evento eu poderia fazer assim, essa sessão aqui, o meu camarote lá, tem 10 lugares. Então ele já geraria aqueles lugares. Eu poderia ter até um, sei lá, algum algoritmo para poder gerar os nomes dos lugares ou atribuir ali alguma identidade para eles. Mas um evento pode desencadear ali em outro evento. Posso ter vários eventos sendo propagados por um comando. Então significa que criar uma sessão do evento acaba propagando uma sessão de evento criada e spots gerados. Mas depois também eu posso querer prover alguma informação ali para o spot, desativar ele ou reativar de volta por algum motivo. Então, eu tenho configurar a informação do spot, informação do spot configurada. Vou colocar aqui configurado. Um evento teria que ser publicado para que ele esteja disponível para venda. Eu não posso deixar o parceiro ir fazendo todas as informações lá. Eu tenho que perguntar para ele, olha, você está aí com todas as informações, você quer publicar, ok. Depois que ele der esse ok, que aí de fato eu vou deixar esse evento ficar disponível para venda. Então eu tenho do parceiro um comando de publicar evento, evento publicado. Já o cliente, eu tenho reservar, tem que ser sempre no infinitivo aqui. Reservar lugar, reserva iniciada, e aí isso aqui vai ser o que a gente tem aqui em cima. Nós temos uma política, que é algo que acontece quando que é algo que acontece quando um evento acontecer. Então aqui eu tenho um enviar dados para gate de pagamento. Aí eu posso ter a reserva aprovada ou a reserva rejeitada. Entende que isso aqui dá uma visão totalmente para a nossa modelagem? Então, das policies eu já falei, e aí eu posso montar uma cronologia. A gente pode montar aqui uma modelagem bem específica. Eu posso ter toda a cronologia que eu já mostrei ali em cima, do parcerio criando evento, criando sessão, configurando o spot, e também toda a questão do cliente. Aí, eu posso querer ver a relação entre os contextos. Olha só. Eu tenho o contexto de eventos, certo? Então, quando... Faltou até uma setinha aqui. Quando eu vou criar um evento, isso aqui é o agregado de evento, e vai disparar o evento criado. Então, o comando chama o agregado, e o agregado dispara o comando. Aí, lá, o de criar a sessão. Chama também. Então, olha só que o agregado é que está controlando tudo. Eu posso ter mais coisas dentro desse agregado, mas aqui eu só quero ver esse agregado. Inclusive, aqui está até errado, porque eu tenho que colocar... Não é um evento que está disparando o outro aqui, na verdade. Inclusive, eu vou até inverter isso aqui. Isso aqui vem para cima e vem para cá. Na verdade, eu vou ter a sessão criada e os spots gerados. Acaba que um evento é dependente do outro, porque quando eu tiver uma sessão criada, eu tenho spots gerados, mas eu vou deixar dessa forma aqui. No caso do pagamento, o que acontece? Quando eu tenho a política que aconteceu depois da reserva iniciada, e a minha reserva foi aprovada, essa barra amarela representa um limite entre os meus contextos. Eu vou acabar enviando esse evento, que são os dados da reserva, e vai acabar sendo enviado um e-mail para o cliente, que é uma policy, gerando um e-mail enviado, que eu poderia fazer uma outra coisa com isso. Mas a gente vê aqui a comunicação entre os dois contextos, a separação ainda mais refinada. E aqui a gente vê que essas duas aplicações, elas podem ser microserviços, elas podem estar separadas, mas elas podem estar dentro da mesma aplicação também. Isso não impede, eu posso criar um monolito, mas deixar essa separação bem explícita. Lá dentro eu sei que eu vou ter a parte, um módulo de eventos, melhor, um módulo de e-mails, e o módulo é eventos, porque eu estou lembrando de eventos de domínio. Eu posso ter um módulo de eventos e um módulo de e-mails. Mas eu sei que são contextos separados, que têm uma linguagem separada e têm as suas devidas responsabilidades, segundo o que a gente já conversou nas últimas aulas. Então, eu deixo aqui esse event storming como uma técnica muito importante. Se você quiser trabalhar com DDB, como uma técnica muito importante, se você quiser trabalhar com DDD, ela vai ajudar não só a ter essa visão aqui, mas ela ajuda na comunicação também, porque uma vez que você esteja numa reunião online ou numa sala com os domain experts, com todo mundo ali envolvido, isso aqui cria uma linguagem ubíqua, ouvido, isso aqui cria uma linguagem ubíqua, cria uma linguagem que a gente consegue conversar, ir entendendo e refinando esse domínio. Então, não é só necessariamente os post-its, mas é uma forma, de fato, de a gente entender o problema, porque é indispensável que a gente saiba todos os desafios, as questões, que a gente extraia todas as informações dos domain experts. Às vezes, você fica ali em entrevistas maçantes e coisas assim, e a coisa não sai. Você sente que as informações que você precisa não estão surgindo. Então, o Event Storming pode ajudar nesse caso, porque toda essa forma aqui de cores, de post-its, acaba nos ajudando a ter uma comunicação melhor. Maravilha, pessoal. Então, vamos seguir na nossa saga. É isso aí e até a próxima.