Salve, beleza? Continua essa saga aqui no Domain, Dreaming e Designing. Agora vamos falar uma coisa que muita gente gosta e que você provavelmente já sabe, mas o conceito dele dentro do DDD é diferente do que a gente está acostumado. Então vamos falar sobre repositórios. Então já vem uma má notícia mais uma vez Para o que você já sabe dos seus ORMs Provavelmente o seu ORM trabalha com esse conceito de repositório E esse conceito não é o mesmo conceito do DDB Ele até, de certa forma, é parecido A gente pode dizer assim Então, a gente estava conversando aqui sobre Como criar entidades, agregados, objetos de valores, etc. A gente vai fazer todas essas operações. Tudo isso está na memória da nossa máquina, mas eu quero gravar isso no storage de dados. Então, quem é responsável por fazer esse armazenamento não é o seu agregado, não é a sua entidade, ele não deve conhecer essas questões de armazenamento justamente para a gente poder manter a riqueza da nossa modelagem. Quem deve fazer essas operações são os repositórios. Inclusive, não só as operações de escrita, mas as operações de leitura também. Mas por que o repositório que você sabe do seu RM não é igual ao do DDD? vamos copiar esse carinha e colocar ele aqui, ele está copiando lá para baixo então eu tenho aqui o meu repositório com um monte de coisas não precisaria disso vou deixar somente as informações aqui eu não quero ter muitas coisas, mas eu tenho aqui o meu agregado então um repositório tem uma relação de um para um Tem muitas coisas, mas eu tenho aqui o meu agregado. Então, um repositório tem uma relação de 1 para 1 com esse agregado. Logo, nós vamos ter aqui o repositório do evento. Então, aqui dentro desse repositório, nós vamos ter lá as operações de criar, e quando a gente está falando aqui, poderia talvez ser um inserir, para poder tirar aquele conceito do criar, atualizar, excluir, pegar um, pegar vários, eu precisava também fazer aqui um filtro. Então, aqui dentro do repositório, eu não tenho, isso aqui é muito normal, não tenho reservar evento. Eu não tenho cancelar evento. Isso aqui são operações que dizem respeito às entidades e não ao repositório. O repositório só lida com o armazenamento daquele agregado. Então, temos aqui a relação de 1 para 1. Relação de 1 para 1? É, relação de 1 para 1. Sempre um agregado, sempre vai ter um repositório. Mas e se eu precisar fazer alguma coisa em event spot? Aí que a nossa cabeça começa a ficar travada exatamente por conta dos vícios do RM. Não, você não tem um repositório para event spot, porque lá no seu RM você criaria um para eventos pode porque lá no seu rm você criaria um para eventos pode você criaria um para evento e um presente pode no caso do ddd não repositório só lida com o agregado como um todo então se você precisa fazer algo de spot vamos supor que seja uma consulta específica, inclusive vou até colocar aqui um X ao vermelho, vou colocar aqui um X vermelho como atenção a gente não tem essas operações aqui Inclusive eu acho que eu exagerei Não tem Isso aqui Se você precisar Eu quero ter aqui alguma consulta... Eu quero consultar eventos que eu tenha spots não reservados. Então, você vai simplesmente criar um consultar por spot. E aí ele te devolve sempre tudo isso aqui. Tudo isso aqui devolve. Aqui devolve. Aqui no inserir não precisa. E aí também vem o costume que a gente normalmente tem. O inserir tem que devolver alguma coisa. Às vezes você pode colocar aqui por conveniência devolver o próprio evento, mas a princípio aqui seria void. Atualizar também seria void. Excluir também seria void. Mas e se não excluir? Você pode simplesmente lançar um erro. Ah, estou pegando um só, então devolve evento. Estou pegando vários, devolve uma coleção de eventos. Eu estou consultando por post, e aqui devolvo uma coleção de eventos também. É justamente para que a gente mantenha o controle sobre as coisas em cima do agregado. Eu não fico devolvendo aqui um event spot, porque senão a gente começa a diluir essa regra de negócio, a diluir essa responsabilidade que é da raiz do agregado para as entidades filhas e acaba se perdendo o controle. É justamente sempre tudo em volta do agregado. Mas nós podemos ter um pouco de variação aqui nesse repositório, se caso seja necessário. Quais seriam essas variações? Dependendo da situação, você pode ter algum método que não necessariamente tenha que retornar o agregado só. Você não é necessariamente tenha que retornar ali o agregado só e não é necessariamente obrigado a retornar somente o agregado inclusive deixa eu até colocar aqui o... vou receber aqui o evento o evento... aqui o evento também... aqui eu posso passar o evento id e aqui poderia ter um filtro se eu quisesse e aqui vem o consultar na verdade aqui eu coloquei constar por spot pegando aquela ideia de não reservado mas aqui eu poderia constar por sei lá, por spot ID eu só tenho o ID do spot e quero constar qual é o meu evento as vezes tem alguma situação que você precisa retornar uma informação mais complexa e aí você pode usar aquele conceito, o Verham fala disso no livro vermelho também, de objetos de valores. pode usar aquele conceito, o Verham fala disso no livro vermelho também, de objetos de valores. Um repositório pode retornar um objeto de valor, às vezes um objeto de valor pode conter lá dentro o evento e algumas outras informações, porque esse objeto de valor é imutável, ele é livre dos efeitos colaterais, e ele vai se auto-validar também. Então, às vezes eu poderia retornar aqui uma outra... Vai que você tem alguma informação de... Você não colocou data de criação, aquelas questões de soft delete, etc., dentro da própria entidade, você quer criar um objeto de valor para poder retornar, você pode retornar também. Mas o que você deve evitar principalmente é na hora de fazer a escrita. Não passe aqui nada a não ser o próprio agregado. Já na consulta, você pode ter uma diferenciação aqui, mas não é para a gente poder ficar, ah, eu quero consultar somente o spot, eu quero ter alguma coisa do spot. Não, não faça isso aqui dentro desse repositório. Se você começa a ter necessidades que talvez carregar o seu agregado por ele ser grande ou por não ser conveniente ali manipular o agregado não é legal, aí a gente tem outro conceito que você pode agregar para te ajudar nessas situações, que é o DAO. Que é o Data Access Object. O DAO é uma espécie de repositório, que é o Data Access Object. O DAO é uma espécie de repositório, só que aqui a gente não tem todas as preocupações com agregados. No DAO, eu poderia ter preocupações mais específicas de performance de banco ou coisa assim. Eu quero fazer alguma consulta para poder trazer dados mais diversos. Uma consulta mais específica. Então, você vai lá e cria um evento DAO. Deixo isso bem claro. Deixo o repositório justamente para ser o irmãozinho do agregado. Até essa relação de intimidade. O DAO aqui, a gente poderia ter uma consulta específica que retorna um objeto que não tenha nenhuma ligação com o DDD, ou tenha consultas complexas para poder usar em relatórios ou algo do tipo. Aí sim, o DAO entra nesse sentido. Você vai lá, cria o seu DAO, aí você pode ter um DAO para o evento, você pode ter um DAO para a tabela de spots, geraria lá uma tabela de spots, aí você gera lá o DAO também. Porque a gente não tem compromisso, o DAO pode ser criado por tabela. tabela. Eu tenho o DAO do Event Spot, conforme seja necessário fazer alguma coisa. Mas não use esse DAO, tenha muito cuidado para ficar fazendo operações de escrita. Porque a gente está criando o agregado justamente para poder fazer o controle da consistência, para poder garantir que a regra de negócio está consistente lá no nosso banco de dados. Normalmente o DAO tem mais preocupações de consulta, ou às vezes alguma questão de escrita por alguma conveniência que tem que ser uma decisão muito sábia que você tem que tomar no projeto. Então, é justamente isso. Se eu tivesse aqui também o parceiro, o parceiro teria um repositório. O consumidor, que seria o cara que compraria o ingresso, também teria um repositório para ele. Então, a gente tem que entender justamente essa diferença dos ORMs. Dentro dos repositórios do DDD, eu posso usar lá o repositório do meu ORM para poder operacionalizar com a tabela do banco de dados. Mas essa diferença tem que ficar bem clara. O repositório que os ORMs estão criando, justamente, eles estão falando assim, tem aqui essa intimidade com a entidade minha, com a entidade anêmica. Então, você pode ter um por ela, porque o foco dele é justamente o banco. É fazer um direcionamento para você poder lidar com a persistência diretamente com a sua tabela do banco. Já o repositório do agregado, não, é eu passar aqui no caso de escrita, eu passar do agregado, não, é eu passar aqui, no caso de escrita, eu passar o agregado inteiro e esse cara garantir que toda a complexidade do agregado seja persistida no meu banco. Se eu precisar consultar, eu carrego aqui todo aquele estado do agregado e dou lá para quem quer processar, que seria a nossa camada de serviços, pessoal. E lembrando aqui do X, não faça isso aqui, isso aqui está absolutamente errado. Se você tem que fazer isso aqui, isso tem que estar dentro do seu agregado. Show de bola. Então, vamos continuar nossa saga, é isso aí, e até a próxima.