Vamos lá. Como é que a gente começa mudando isso aqui? Bom, de cara, a gente pode pensar em separar a par de dados. Isso tem muita relação com o próprio portion adapters, que vocês também estão estudando em paralelo, e que diz que a gente deve, como eu falei, o driver é separado da aplicação, ou seja, do que a aplicação está expondo e os recursos que ela consome também devem ficar separados para que eu possa variar polimorficamente por exemplo, eu poderia fornecer no teste talvez um repository já trazendo outro padrão aqui antecipando em memória ao invés desse que acessa o banco de dados então vamos lá. O que eu vou fazer aqui? Eu estou lidando com quem? Eu estou lidando com contracts. Então, vamos começar por aí. Vou criar um negócio chamado contracts repository. Repository. E aí a gente começa a falar já de padrões ligados à persistência e o repository ele é um padrão eu até vou anotar aqui patterns repository o repository ele é um padrão que tem como objetivo realizar a persistência de aggregates o que de aggregates. O que são aggregates? São clusters de objetos de domínio, como entities e value objects. Coisa que vocês estão estudando em paralelo também. Então, essa é a ideia do repository. O repository não é um padrão que persiste em qualquer coisa. Ele é um padrão que visa realizar a persistência de aggregates separando essa responsabilidade do domínio não só do domínio, né? Essa responsabilidade da aplicação. Você não tem essa responsabilidade dentro da aplicação. E quando eu falo aplicação, eu me refiro, de novo, a isso aqui, tá? Eu tiro essa responsabilidade da aplicação e delego para o repositório. O que vai acontecer aqui? Ele vai ser uma interface. Export, Default, Interface, Contract, Repository e agora complica um pouco. E complica um pouquinho, porque a gente vai ter que ter a seguinte mentalidade aqui. Qual é a operação que eu vou fazer por meio desse repositório nesse caso vai ser o seguinte me lista os contratos e dá os contratos ponto poderia pedir um contrato específico por ID poderia pedir contratos por data, não tem problema me lista os contratos, acabou, ponto final o que eu vou fazer aqui agora contratos por data, não tem problema, me lista os contratos e acabou. O que eu vou fazer aqui agora? Eu vou ter uma possível implementação desse repository que vai ser o ContractsDatabaseRepository. Então é a versão deste contract para obter dados do banco. Então, export default class contract database repository. Então, por menorzinho do porquê que é um aggregate, que a gente vai ver agora. Então, vou fazer o implement aqui. Contract repository. O que que fica aqui? Vamos lá, vamos separar agora as coisas. A conexão fica lá? Olha, na falta de um lugar melhor fica lá Isso aqui fica lá? Os contratos ficam? Claro, não tem dúvida Para cada contrato Agora aqui vem um pormenor Para cada contrato agora aqui vem um pormenor para cada contrato eu tenho pagamentos aqui o bicho pega porque é mais ou menos o seguinte deixa eu só copiar certo porque está quebrando a linha se você diz que você tem um repository isso quer dizer que você está que você tem um repository, isso quer dizer que você está retornando aggregates. Aggregates são clusters de objetos de domínio o que mantém a invariança, o que mantém a coerência entre eles. Então, não faz sentido se no seu domínio não faz sentido você dissociar pagamentos de contrato e, normalmente, quando você está orientando o domínio, você quer agrupar as coisas de maneira que você preserve essa coerência, essa invariança. Se é o caso aqui, e aqui que está o conceito do padrão repository, eu tenho que trazê-lo junto. Se fosse um DAO qualquer, eu poderia ter contract DAO e payment DAO. Orientado à tabela. Aqui a orientação não é tabela. A orientação é Aggregate. Aggregate é um grupo, é um cluster. E eu estou entendendo que esse cluster é formado por dois, vou citar aqui, duas entidades. Contrato e pagamento. Ou pagamentos. Tá bom? Então, return. Peguei aqui os contracts, iterei, peguei os pagamentos do contract e devolvi. Vamos lá. PG promise I'll have to allow. Não tenho mais essa responsabilidade aqui. Tá bom. Agora ficou uma bagunça aqui, né? Não temos mais isso aqui. Vou dizer, ó. Contracts é igual a wait. Bem, cadê o repository? Vamos começar da seguinte forma, tá? Contracts repository é igual a new contract database repository, tá bonitão aí? Contract rep, list, fechou, trouxe pra cá. Payments, contract.payments, e aqui, esse fechamento de conexão, Trouxe para cá. Payments. Contract.payments. E aqui, esse fechamento de conexão, ele vem para cá. Vamos ver se funciona? Vamos ver o que aconteceu. Funcionou. O que a gente está fazendo aqui é design, é atribuição de responsabilidade. Então, olha o design pattern. Usamos um repository que realiza persistência de um grupo, chamado aggregate, tirando essa responsabilidade da aplicação, que nesse caso está expondo o Generating Voices. Então, o fato de a gente tomar a decisão, eu vou pegar essa parte que lida com dados e vou levar para lá. Agora eu tenho o generate invoice e o contract database repository. Separar essas responsabilidades é uma decisão de design. E esse design foi permitido pela arquitetura que eu escolhi que trouxe o princípio o paradigma orientado ao objeto se fosse outro paradigma, talvez eu não poderia ter usado esse padrão não estou dizendo que a orientação ao objeto é melhor que o outro só a escolha que foi feita a gente ainda vai evoluir um pouquinho mais essa ideia do repositório isso ainda não é 100% um repositório a gente ainda vai amadurecer mais. Muito bem, seguindo adiante. Reparou que a gente tem o repository, mas a vantagem dele ser polimórfico, ou seja, a vantagem dele me trazer uma interface, um contrato, que para muita gente às vezes é uma coisa que, ah, eu vou criar interface por criar, sei lá, porque, sei lá, é o padrão aqui da empresa, porque eu li num artigo que tinha que criar interface mas a interface, o uso de um contrato tem um propósito, e esse propósito é justamente ser mais polimórfico, o que eu quero dizer com isso se eu rodar esse teste, vamos fazer uma experiência vou vir aqui no banco de dados no script banco de dados. No script. Banco de dados. Vou comentar essas linhas todas. Eu vou dropar o banco. PSQL, DEP, F, CREATE. Dropei o banco. Olha. Se eu rodar o teste, vai funcionar? Não. Ela nem existe então existia um acoplamento entre o meu teste e o meu banco de dados e que me impede de testar essa aplicação na ausência dele vou rodar o banco de novo vou rodar o teste novo e aí funciona então a grande sacada aqui é que eu poderia ter vindo no teste e ter dito assim, olha e se eu pudesse ter o controle dessa dependência, olha que lindo isso o controle dessa dependência que é o contract repository mas eu posso ter