Understanding the correct time to have Provider, Repository, DataMapper and DAO layers in the application

I am designing a new application and I wanted to use it as a boilerplate for future projects.

In this application I need to access data from different sources like a MySQL database, Mongo and also from a remote server. Users, for example, have information in both databases. But some other entities exist in only source.

So from my understanding DAO is very Database specific. It is also a generic implementation of database queries.

Repository is more business specific and also implements an interface for persisting and retrieving data (but for the use cases). It may use DAO objects, but could use other Repository objects as well.

Provider is not new to me, but I'm not very familiar with. When I used it, it was meant to access remote services.

I remember having DataMapper in a project I worked on, but reading the definition of the Pattern makes me confused. It sounds a lot like a ORM (or ODM).

So, what do you say? Where should I implement the communication with the remote service, in the Provider? Can I have both Providers and Repositories? Providers can instantiate Repositories and vice versa? Can DAO send requests to remote APIs? Does DataMapper makes sense when I already have Repository (and maybe Providers)?