I've used these patterns for years now in software I make depending on complexity of the software. They are used to abstract access to external data services including MySQL, RocksDB, ElasticSearch and etc.
A DAO object abstracts the specific database access and includes CRUD methods. A Repository represents a collection of data objects an amalgamation of DAOs essentially.
Think about it, if you had User Account information, you could store it into a K/V db while indexing the information in a search database like ElasticSearch. If you wanted to search for user by name, then typically you'd need a Repository with that method and two DAOs. I'm not saying that you always need to create a DAO though considering a static list of objects can be part of the Repository as well, but you might as well abstract that collection.
- RocksDB -> UserAccountDAO -> UserAccountRepository
- Search DB -> UserAccountSearchDAO -> UserAccountRepository
- UserAccountRepository (findAccountsByName, selectAccountsByCreatedOn, filterAccounts, etc)
The repository object can then be used by business logic to do whatever you need to do. This is not to say that a Repository class always need to be created.
Consider MySQL, you can utilize its versatility and index the accounts there and write SQL. A DAO can be used directly instead and the typical repository methods moved up to the business logic. Where the methods go are totally dependent on you and your implementation.
Same with the models. A repository can return a domain object or persistence object depending on needs, but there is no reason to stay restricted to one or the other as that will cause unnecessary transformations and hydration which are the typical downfalls of object mapping libraries. Keep it simple, don't do it just because you can, keep original models around until they are unneeded.
No overthinking is needed as you can refactor into patterns when appropriate. No need for 1:1 Repository to DAO methods or models for that matter.