Meu raciocínio sobre repository é bem nessa linha que você citou Branas. O repository não quer saber como a persistência é feita, desde que o objetivo seja persistência de objeto de domínio, assim faz muito sentido repository chamar api ou qualquer outro tipo de serviço que esteja no mesmo contexto.

eu concordo demais. principalmente pelo que foi dito no final. tendemos a respeitar a interface do repository, que, por sua vez, respeita do domínio da aplicação, então não importa de onde vem o dado, o repository vai caber... não tem sentido dizer que o repository é exclusivo de banco de dados

Seria interessante mostrar isso em um caso real, exemplo um DB da AWS que vc acessar via SDK ou mesmo web API.

Um caso, é o meu, atualmente cuido de um software de integrações, basicamente temos o produto principal (outra equipe) e o cliente tem outro ERP que ele quer unir, o meu projeto cuida da integração desses dados entre os dois ERP's, e para fazer o CRUD no meu banco, por razões de negócio (replicar tudo que a API do software principal faz é inviável), a gente faz a persistência via API, então para gente, nosso repository, são HTTP requests enviado no end-points da API do software principal

Excelente, concordo; Por exemplo, ao usar o S3 da AWS para armazenamento, o repositório interage diretamente com a API do S3. Isso mostra que um repositório pode se adaptar a diferentes meios de persistência, mantendo sua função essencial de mediar entre o modelo de domínio e a camada de dado; Neste contexto, atua como uma interface abstrata que esconde os detalhes de implementação e interage com o S3 através de sua API

Passando aqui pra fortalecer no like. Esses novos conteúdos focados em ddd estão tops.

Sou da epoca do AngularJS, seu conteudo é muito bom mano. Pretende fazer algum curso do Angular atual? aprendi mt com vc

Sensacional, Branas. Ótimo contéudo!

comentario fora do contexto: to gostando demais do branas low profile, espero que essa fase dure bastante, só gratidão pelas dicas de tecnologia!!!

No Back chamo de UseCases e Repositories, no Front Chamo Services e Gateways

Análise perfeita.

Boa tarde. Antes de mais, parabéns e obrigado pelo um excelente conteúdo que fornece gratuitamente aqui no youtube. Gostaria de colocar uma dúvida que tenho andado estes últimos dias a tentar esclarecer e que não estou a chegar a nenhuma conclusão. O fluxo normal de uma ação de um utilizador será ui -> Caso de uso -> criar ou obter objetos de dominio e por fim se existir essa necessida chamar um repositório para guardar as alterações feitas num objeto de dominio. Sendo este o fluxo normal quando desenvolvo um aplicação começo por desenvolver o dominio e posteriormente os casos de uso, contudo neste último devido a alguma formações e videos que vi dizem que um caso de uso não é representativo de frontend ou backend e desta forma a implemtação deve ser sempre a mesma. Dando um exemplo, pretendo fazer um contador, teria um Contador como entidade e teria um repositório para o contador para guardas as alterações que sejam feitas nele. Caso um utilizador queira incrementar o valor do contador chamaria um caso de uso Incrementar com o id do contador como parametro, o caso de uso tenta obter o contador através do repositório, altera chama a função incrementar da entidade e depois volta a guardar as alterações através do repositório e o caso de uso ficaria completo e não está importado que tipo de aplicação está a usar este caso de uso, se uma api, se uma aplicação frontend react ou vue, o caso de uso deveria ser o mesmo. (Aqui uma dúvida que tenho é se realmente o caso de uso seria o mesmo para frontend e backend) Caso o caso de uso possa ser o mesmo, ao tentar implementar isto num frontend utilizando por exemplo react e pensando que tenho um repositório, o que seria este repositório? Poderia ser um repositório em memória ou uma chamada a uma api, mas sendo um repositório em memória, faz sentido guardar dados no repositório e guardar dados num useState do react pois sempre que incrementa um valor a página do react deve ser atualizada? Esta dúvida é um pouco extensa e não sei até que ponto teria um tempo para a responder num possível video ou mesmo respondendo aqui mas ajudaria-me imenso a ver este tema que me tem desgatado porque não consigo encontrar uma resposta para este situação. A única forma que é vejo de fazer isto é ter casos de uso especificos para frontend e backend e o frontend não teria o caso do repository e sim, sempre que é necessário alterar uma determinada infromação que não necessite de aceder a uma api, que apenas faça uma alteração em memória, os dados ficariam guardados no react e o caso de uso receberia um objeto de domino, mas isto também deixa de fazer sentido porque o caso de uso já seria o próprio componente do react e ele mesmo interagia com os objetos de domino. Se conseguir responder ficaria muito agradecido ;)

Um repository acessar uma API, pelo menos pra mim, demonstra um anti-pattern profundo. A primeira pergunta que eu faria: pq fazer um repository acessar uma API ao invés de acessar uma API via service que, por fim, realiza a persistência? Uma segunda pergunta: se eu preciso realizar operações alheias à persistência, pq não fazer isso na camada de negócio antes de tentar a persistência? Apesar de que, na teoria, a idéia de utilizar um repository é abstrair a camada e não ter a necessidade de saber o que acontece, apenas que aconteceu, fazer essa interpretação elástica permitindo um repository acessar uma API pra então realizar a persistência é criar mais pontos de falha, aumentando a complexidade do sistema, do seu desenvolvimento e do rastreamento de falhas. Em suma - um repository não se conectar diretamente com a persistência me parece firula desnecessária, apesar de, pragmaticamente falando, ser válido.

Branas to sem rede social, coloca aqui tb os videos. obg em breve estarei em uma de suas terumas

🎉🎉🎉 você e lendário 🎉🎉🎉 seus vidoes e peojrtos a anos ❤🎉

conceito de /health no backend, verifica a saude do contêiner, como podemos fazer a mesma coisa no contêiner do front, o que é mais usado no mercado em relação ao /health para frontend ?

meu palpite é que este cenário só se torna válido quando você abstrai totalmente a forma em que este repositório consegue persistir/consultar dados. E que esses dados representam dados não necessariamente relacionados ou cruzados com outro domínio da aplicação que realizou o procedimento

Resumindo, este é o problema de videos curtos(shorts), você não consegue dar estes detalhes para explicar um conceito em detalhes.

"Não concordo nem discordo, muito pelo contrário." Excelente conteúdo

Já vi o PostgreSQL ter o recurso de API, ao meu ver seria o melhor caso do uso do repository consumindo uma API.Acho que é PostRest, pensando o comportamento será de um repository ok. Contudo ou usar repository ou usar Gateway. Ao meu ver Usecase->Repository->Gateway não estaria certo. O que acha ?

Galera, sei que não tem muito a ver com o assunto, mas gostaria de uma orientação. Recentemente, trabalhei nos sistemas de uma empresa que possui APIs distribuídas, sendo que uma API consome informações de outras da mesma empresa. Dentro dessas APIs havia vários códigos espalhados com as chamadas para essas APIs internas, então, eu criei uma biblioteca (artefato do Azure DevOps) e estou colocando esse código dentro dessa biblioteca, de forma a ter uma classe base, que faz as requisições e devolve as respostas. É uma boa prática ?

Branas, faz mais vídeos, com tema DDD e TDD, um abraço, você é fera.

fazer chamada http pro banco é chamar uma api

Se o repository não for exclusivo para o banco de dados eu poderia fazer uma chamada externa de dentro dele para outra API para complementar os dados de uma consulta do banco de dados. Sendo que essa chamada externa poderia ficar na camada anterior de service, e se precisace de alguma lógica pra montar o objeto pra devolver pro gateway ou controller ficaria em uma camada para melhor refactor.

Eu tenho a primeira edicao desse livro do martiwn fowler, em portugues, e nem tem essa capinha preto e vermelha 🤭🤭🤭🤭