Salve, das Belezas! Continuamos a saga aqui no Domain Dreaming Design. Agora vamos começar a trabalhar com os repositórios. Nessa aula, nós vamos criar um contrato para que os nossos repositórios possam implementar. A gente tende a fazer isso nas nossas aplicações, porque, dado ali as peculiaridades dos repositórios, mesmo assim eles vão ter algumas igualdades. Então nós podemos continuar utilizando esse column aqui para poder registrar tudo que é compartilhado aqui no nosso projeto. Então eu vou criar aqui dentro um repository interface.ts. E nós vamos ter aqui uma interface do TypeScript, que eu vou começar com i. Acho que é uma boa anotação, a gente bate o olho ali e já sabe que é interface, não precisa colocar interface no final. Isso aqui deixa bem claro, porque repositório sempre é criado apenas para os aggregate roots, ou as raízes do agregado, nunca para as entidades. Então, vou usar um generic aqui, falando assim, que a entidade que a gente passar tem que ser exatamente o aggregate root. Isso aqui deixa bem claro, mas o que isso aqui vai ter de vantagem? Porque nós podemos criar aqui os métodos. Métodos focados para a gente poder fazer a nossa persistência. Então, lembrando que não tem reservar, não tem operações de negócio. A preocupação é apenas armazenamento. Então, eu poderia começar pelo save. Seria o mais... adequado aqui, mas a gente vai chamar isso aqui de add. Às vezes a gente pode querer criar tipo um insert ou um update e não está errado. Mas como a gente está trabalhando com esse Unit of Work, ficaria estranho, vai fazer sentido quando a gente usar esse repositório, vai ter lá um ponto insert, mas a gente não vai estar inserindo, na verdade, vai estar só adicionando a entidade ali na pilha de objetos que depois, quando ser feito o flash que vai descarregar de fato as operações então esse insert fica um pouco esquisito o uned fica mais interessante porque deixa claro que estou fazendo estou adicionando numa coleção ele não vai vai, de fato, naquele momento, não vai ser persistido. Então, a gente pode ter um add, pode ter um find by id, então o add vai contemplar tanto o update quanto o insert, um find by id nós podemos ter aqui também. Aí eu vou passar assim o id n, aí cada repositório implementa de alguma forma, eu devolvo a própria instância do agregado ou um nulo. Um find all, de praxe, se a gente quiser pegar todos, e um delete, passando aqui o id, pode ser qualquer coisa, o repositório também implementa. Olha, que no add e nem no delete nós não temos o retorno dessa entidade, ela já está devidamente configurada com todos os dados, não tem por que a gente retornar uma nova instância. Se você quiser colocar por alguma conveniência, pode. Beleza. Então, esse aqui é o nosso contrato que todo mundo vai utilizar. Aqui tem um outro detalhe também que costuma ser um embate na comunidade. Onde ficaria esse conceito de repository? Se ele fica na camada de domínio ou se ele fica na camada de aplicação que a gente não chegou a trabalhar ainda. Algumas pessoas vão dizer que é na camada de aplicação que a gente não chegou a trabalhar ainda. Algumas pessoas vão dizer que é na camada de aplicação, outras pessoas que é na camada de domínio. Na aplicação, a justificativa é que os repositórios são usados só na camada de aplicação. Eu gosto de colocar no domínio porque eu acho que ele representa um conceito do nosso domínio apesar de ser usado na camada de aplicação. Mas isso aí é apenas eu considero um mero detalhe. Agora, dentro aqui do nosso domínio, nós vamos criar um repositories e aí um partner.repository.ts E aí nós vamos fazer a importação da nossa interface. Inclusive, como isso aqui antes vai ser uma interface também, eu vou colocar um interface aqui nesse caso, que o nome do arquivo seria interessante, ou no mínimo poderia colocar um i aqui na frente. Esse padrão que eu estou utilizando aqui convém mais utilizar essa interface. Então, eu vou exportar uma interface que é o Partner Repository Interface que vai estender lá do nosso contrato e Repository Partner. Show de bola! Então ele vai exigir que... antes eu tenho que fazer a importação, ele vai exigir que eu implemente todos os métodos. Então vamos... cadê a... tem que importar o partner aqui também que eu não importei ele já dá uma opção para poder fazer a implementação engraçado que não tá então... ou não vi ali, então vamos pegar todos os... Na verdade, eu não preciso, eu estou pensando que é só a interface. Não vai exigir, justamente está correto. Aqui vai ter um erro do slint, que ele vai falar assim, peraí, você tem uma interface que está equivalente ao supertipo. Nesse caso aqui, eu não tenho nenhum método específico para implementar no momento, então eu vou colocar um comentário aqui em cima. Vai desabilitar a verificação nessa linha, o no empty interface ali. Em repositórios, a gente sempre vai tender a ter alguma coisa mais específica. Pode ser aquela sugestão ali que ele está fazendo um igual, a interface em si também seria uma opção, mas eu gosto de deixar isso aqui bem transparente. principalmente para poder fazer algumas consultas. Ah, eu quero buscar por algum critério, passando o objeto mais complexo. Então, fazendo dessa forma aqui, faz com que a gente possa fazer a implementação com a nossa tecnologia principal de ORM, mas de outras formas também. Eu vou salvar isso em outros lugares, eu tenho uma variação, então isso fica lá na infraestrutura, mas eu sei que esse contrato deve ser respeitado, que está aqui no meu domínio. Então na próxima aula a gente vai implementar esse repositório, que na verdade vai ser muito simples por conta que a gente está trabalhando com esse Unit of Work, Data Mapper e o MicroRM, e nós vamos entendendo como vai funcionar esse processo. Então vamos continuar