Salve, beleza? Continuamos essa saga aqui no Domain Dream Design. Agora o nosso desafio é resolver aquele problema da venda, simular aquele problema da venda com o Domain Dream Design, como a gente modelaria ali a venda, a reserva, na verdade, do ingresso com o Domain Dream Design. Claro que a gente não vai conseguir contemplar tudo, inclusive tickets. Eu não vou mostrar aqui porque a gente teria que fazer uma outra construção. Quem sabe a gente não pode até adicionar em off esse exemplo. Mas vamos nos concentrar na reserva em si. Então, nós vamos ter dois agregados para poder lidar com essa reserva. Primeiramente, o agregado de order ou do pedido que foi feito pelo próprio cliente. Então, ele vai ser um aggregate root, vai ter o ID dele que é um new ID conforme a gente já está trabalhando, o ID do customer, qual é o preço que foi pago naquele momento, qual é o spot ID que nós estamos relacionados, eu posso me relacionar com o child lá do agregado sem problema nenhum. E qual é o status da order? A princípio ela vai estar pendente, depois ela vai ser paga ou cancelada, porque não vai ter meio termo, não vai poder esperar, porque a gente não está jogando isso para nenhuma fila, ou em background ele tem que resolver na hora. Maravilha. Então, na hora de construir aqui o construtor, tem lá o ID, que se for string, cria ali o objeto de valor, senão ele vai acabar gerando, tem o Customer ID também, que é o relacionamento, a gente pode receber uma string que também é feita a análise e o SpotId também é a mesma coisa, inclusive eu acho que eu posso até colocar o Amount aqui e deixar os relacionamentos ali para baixo. Então eu tenho um método de criar e o JSON para poder retornar todos os valores. Então retorno aqui o objeto de valor, o valor do Customer ID e do Spot ID também. Beleza, então é isso aqui que a gente tem. E nós temos uma outra entidade que vai servir para a gente poder ter o controle que somente uma pessoa vai conseguir fazer a reserva do lugar. Nós vamos armazenar, e aqui que vem uma outra variação do DDD, que às vezes a gente pensa que sempre tem que colocar um ID específico, que tem que ser único para o agregado. Nesse caso, o Spot Reservation vai ter como identidade o ID do próprio Spot. E a gente vai colocar... Isso aqui, na verdade, vai ser inerente. Isso aqui vai ter uma restrição aqui. Eu tenho uma restrição porque eu só posso um ID. Então, se eu tiver várias pessoas tentando criar ali ao mesmo tempo a concorrência, o primeiro que conseguir gravar é o banco de dados que vai controlar isso para mim. Então, estou delegando ao banco de dados esse controle ali que ele tem a chave de unicidade lá, ele consegue gravar os outros que estão criando. Então, eu tenho a data da reserva que foi feita e o customer. Então, é um outro agregado ali, independente também. A gente consegue, pela order, buscar aqui a reserva justamente porque é o mesmo ID. Então, olha que interessante esse ponto. Essa aqui é a solução que a gente está fazendo para que nós tenhamos ali algumas regras de negócio interessantes. A gente pode resolver essa questão aqui da reserva única de várias formas. Depois a gente vai discutir sobre a implementação, se a gente pode melhorar, o que a gente poderia fazer a mais para tornar esse nosso processo de negócio mais simples e melhor para manter ao longo do tempo. Então, para poder fazer a criação aqui, eu passo ali todos os dados, o ID do spot, o ID do consumidor, e a data de reserva não faz parte aqui da criação, porque é a data que eu estou criando ali no momento. Eu posso fazer a mudança da reserva se eu quiser. Isso aqui é uma outra operação. Vamos supor que a pessoa ali fez um cancelamento, então eu posso abrir para poder fazer a mudança. Então estão aqui os nossos dois agregados. Isso vai resultar na nossa modelagem na parte de mapeamento. Então eu tenho o Spot Reservation inclusive aqui eu não preciso... até coloquei esse Unix aqui, não preciso porque o próprio Spot ID é uma chave estrangeira e uma chave primária ao mesmo tempo, então a gente tem esse controle. Inclusive aqui eu vou até colocar o que eu estou colocando nos outros eu tenho que colocar aqui o hidden se bem que o hidden aqui a gente não quer que a chave primária então não vale a pena aqui vai ser hidden e aqui aquele inherit igual a true show de bola Inherited igual a true. Show de bola. Então, nós estamos reaproveitando o ID do EventSpot ID. Está aqui o relacionamento minute1. Com o customer também a gente reaproveita o ID. Você vai criando os IDs com o mapeamento e vai reaproveitando eles. E a data de reserva aqui, que é uma própria data. Já na order, nós temos o ID lá referente a ela. Aqui tem que ter o hidden também. Vou colocar o hidden aqui. O hidden ali de baixo já está. Esse cara aqui, a gente vai passar o relacionamento então tem que ter um heretato também tem o status dessa ordem que a gente só muda via método aqui, vamos fazer aqui um pay. A gente muda o status aqui para pago e o cancel para cancelado. Eu tenho que ter esses dois status aqui. A gente até poderia guardar o ID da transação que acontecesse num gateway externo, também seria uma outra opção. Mas tem aqui o status, que vai ser um enum baseado no que a gente já tem aqui em cima. Então, primeiro está pendente, depois pago ou cancelado. Aí tem os dois relacionamentos aqui, beleza. Então, esse é o nosso desafio para poder criar a nossa venda. Então, o que a gente vai acabar fazendo? Já vamos, pelo menos, já preparar o terreno, vamos dizer assim. Tenho o Customer aqui. Então, eu tenho um application service para a order a gente pode listar, eu vou fazer aqui o uso da order, eu nem criei também repositório, mas a gente vai criar depois. Então, aqui vem o order repo. Posso listar todas as orders? Faria sentido isso aqui? A gente deixa... Faria mais sentido a gente listar as orders de um usuário, de um customer específico, mas a gente vai deixar aqui dessa forma. E, na vai deixar aqui dessa forma. E na verdade aqui vai ser o... Agora vem o método, o nome do método para a gente poder fazer o nosso registro, ou melhor, a compra. Então, vamos fazer a... Vou colocar como Create mesmo. Acho que está um bom nome aqui eu vou deixar ele limpinho que a gente vai fazer isso juntos então eu tenho esse desafio agora eu tenho que passar alguns dados aqui que a gente vai conceber também e aqui em cima vem order que eu não mudei e aqui também vai ser order a gente pode até criar juntos aqui já em cima vem order, que eu não mudei, e aqui também vai ser order a gente pode até criar juntos aqui já o repositório então aqui vem o repositório e basta fazer a mudança aqui, que a gente muda para order, fica fácil, e aqui vem o order. Falta mudar aqui. Acabou-se os erros de typescript. Acho que aqui também, pelo menos, ele devia sumir esses erros. Vamos só importar novamente aqui para não ter nada. Show de bola. Então, nós temos aqui o desafio do nosso create, operando dois agregados e a gente vai ver uma outra variação que a gente vai entendendo como funciona aqui o Application Service. Então, pessoal, vamos seguindo a nossa saga. É isso aí. E até a próxima.