Salve, beleza? Continuamos essa saga, na verdade, finalizando quase a nossa saga de Domain Dream Design. Agora vamos falar sobre outro assunto importante sobre os agregados também, que é sobre o tamanho de um agregado. Primeiramente, eu vou deixar aqui esse link que está no DDD Community. Você pode achar aqui o site que a comunidade de DDD concentra os artigos e tudo mais. Inclusive, eu vou até... deixar ele aqui. Então, eu encontrei um monte de coisa aqui sobre o DDD. Recomendo você dar uma olhada também. Mas existe um paper do Verno que na verdade é um trecho do livro, do Redbook dele. Então você vai encontrar esse mesmo trecho lá no livro. Sobre o quão pequeno ou quão grande deve ser um agregado. Na verdade, até puxando lá para as regras dos agregados que eu não acrescentei na aula passada, o agregado deve ser o menor possível. Mas isso não quer dizer muita coisa. O agregado representa um processo de negócio que você está trabalhando. E não existe, na verdade, uma modelagem correta. Ah, o agregado tem que ser assim, tem que ser assado, tem que ter até três níveis, ou não. Tudo vai depender do seu contexto. O tamanho do agregado vai definir o tanto que você vai gastar de memória para ficar carregando ele ali e também o impacto que você vai ter para poder salvá-lo no seu storage. Pode ser que seu agregado seja tão grande que para salvar você está gastando um recurso do banco de dados muito grande. Além disso, se ele for muito grande também, vai ter tantas linhas de código que fica difícil você proteger as invarianças que estão acontecendo ali. Então, é claro que se a gente tiver uma classe a menor possível, vai ser melhor. E aí que chega o assunto referente ao que a gente fez aqui. E aí que chega o assunto referente ao que a gente fez aqui. Inclusive, deixa eu colocar aqui. Regras dos agregados. Aí vai chegar o assunto do nosso agregado de eventos, que é o nosso agregado principal ali no tocante ao assunto de agregados. Porque o de order, apesar dele ser importante no contexto de negócio, na questão de modelagem ele é muito simples. Então, a gente tem lá o nosso agregado que tem três camadas. Ele tem duas outras subentidades. Então, eu tenho eventos. Cadê eventos? Aqui. Depois, event session e event spot. aqui, depois eventSession e eventSpot. Vamos fazer aqui uma brincadeira. Eu vou chegar acho que eu já tenho isso aqui deixa eu pegar isso aqui na minha aplicação um parâmetro para você poder ver as consequências do seu agregado é o tamanho dele em memória, porque isso aí serve como um guia. Então vamos pegar aqui o EventsController. E aqui na listagem desses eventos aqui, eu vou pegar eventos com await, retorno eventos aqui para poder manter o comportamento, e aqui embaixo eu vou colocar essas duas funções para a gente poder medir o tamanho em bytes. tamanho em bytes. Então, eu vou passar aqui esse objeto que, na verdade eu tenho que usar esse aqui na verdade é o log mesmo, eu vou colocar aqui Events, que é apenas a descrição, e aqui o objeto vai mostrar para mim o tamanho desse objeto. Na verdade, aqui a gente não está fazendo uma aferição 100% correta, porque a gente tem um tanto de bytes que campos inteiros, float e tal ocupam, o que a gente está fazendo aqui é uma conversão de todo esse objeto para uma string e avaliando o quanto aquela string tem de tamanho. Mas serve como um valor aproximado, verificando baseado em uma string. E aí a gente vai ter uma métrica pra saber ali o impacto disso toda vez que eu estiver lidando com esse agregado vamos fazer aqui o seguinte então eu já estou rodando aqui com a minha aplicação espero que eu não tenha quebrado nada vamos ver se a gente tem um partner a gente tem então vou chegar aqui e vou jogar esse ID para cá e aí customers eu não preciso criar eventos, tá funcionando bonitinho ele mostrou 0 bytes que eu não tenho nada né e aí vamos criar aqui Um evento E agora eu quero criar Uma sessão já com os spots Vamos pegar um caso mais absurdo Aqui baseado no nosso sistema Sei lá Eu posso ter Até 5, um agregado Com 5 mil lugares Eu tenhoregado com 5 mil lugares. Eu tenho um evento com 5 mil lugares. Poxa, já é muito lugar. Então, deixa eu pegar aqui esse event ID. Jogar ele para cá. Vamos criar esse 5 mil aqui. Ele vai até dar uma engasgadinha, porque são muitos os dados, porque também o VS Code aqui não é preparado muito para poder lidar com isso. E agora vamos ver o que a gente tem aqui em relação a bytes, na hora que eu recuperar o meu evento que vai demorar um pouquinho e agora a gente vai ver que eu estou utilizando 500 mil bytes vamos fazer uma conversão eu vou usar a anotação do Wesley bytes para mega então para um agregado que tem 5 mil lugares em total, não interessa o número de sessões não vai fazer grande impacto ele teria meio mega a partir daqui a gente pode fazer uma estimativa do número de usuários que podem utilizar o nosso sistema ao mesmo tempo, com uma chance de parceiros que vão ter eventos desse tipo. Meio mega. Para 5 mil lugares. Isso não está muito alto. Isso não está muito alto. É um objeto muito grande e está consumindo bem pouco. Isso não está muito alto. É um objeto muito grande e está consumindo bem pouco. Mas às vezes eu posso estar fazendo uma plataforma que vai negociar os ingressos para jogos de futebol. Aí a gente está falando de 20 mil lugares, 30 mil lugares, 50 mil lugares. Mesmo assim, deve gerar aqui em torno de alguns megas. Mesmo assim, pode não representar um problema. Então, a gente tem que fazer uma estimativa da nossa infra que a gente vai ter ali no momento. Mas também a gente tem que fazer uma estimativa do quanto que essa aplicação vai gastar. Então, o tamanho do agregado, ele impacta os recursos do seu sistema. Nós podemos chegar a uma conclusão, aí que está o ponto. Eu não quero deixar aqui uma conclusão, porque não há uma conclusão se esse agregado é bom ou não. A gente vai saber com o tempo. Você pode justamente usar uma modelagem que tem um agregado um pouco maior, porque ainda você não é expert no domínio, esse domínio está sendo refinado, e com o tempo esse agregado é quebrado. Isso acontece, você não vai fazer um agregado perfeito, ele vai ficar eternamente no sistema. Mas a questão é que esse agregado, o que eu quero falar para vocês é que eu posso sim ter esses três carinhas sendo um agregado. Mas a questão é que se eu manter a mesma lógica que, ah, eu tenho que ter aqui o número de lugares, o número de lugares disponíveis, se esses três caras são separados, que aí seria o cenário que eu usaria menos memória e também tanto para poder consultar e para poder fazer o controle transacional, mas eu tenho uma proporração da regra de negócio é óbvio que ela está concentrada dentro do próprio agregado se eu tenho agregados menores eu tenho mais dispersão dispersão da regra de negócio. E menos controle. Ela está mais dispersa. Porque imagina só, toda vez que eu fizesse alguma coisa em Spot, eu estou adicionando um novo Spot. Então, através lá dos eventos, a gente vai ter que adicionar mais um nesse Spotar aqui mais um nesse spots e mais um nesse aqui. Está diluído essa regra de negócio. Está mais leve, mas está mais diluído. Então, o que o Vernon fala naquele paper é a gente encontrar a harmonia ao longo do tempo. Não vai ter o cenário perfeito, mas você tem que levar em consideração qual o custo desse agregado para o seu sistema. Porque também não adianta nada ter um agregado muito grande, toda vez que eu vou carregar ele ali é muita memória. Eu estou desperdiçando esses dados muitas vezes, eu estou fazendo o carregamento ali, mas estou usando poucos dados. Então, vale a pena eu fazer essa quebra. E essa quebra, ela não tem também um modo correto. Você tem que fazer uma análise do seu domínio. Então, eu queria deixar isso aqui, que a gente poderia também fazer essa implementação. E aí, claro, se eu fazer essa separação, o EventSession teria um EventID, e o EventSpot teria o Event Session teria um Event ID e o Event Spot teria o Event Session, mantendo ali a regra dos agregados só se referenciam pelas suas entidades. Ah, mas e quando eu precisasse consultar e devolver ali tudo de uma vez só? Vamos supor que tem alguma tela lá minha que precisa de todos os dados. Então, no seu Application Service, você vai ter os três repositórios, faz a consulta lá, organiza aquele conjunto de dados e retorna. Então, é a dispersão. Você vai ter que controlar essa dispersão conforme você precisa. Então, pessoal, é isso aí e até a próxima.