How to deal with DDD with complex queries and local Vs remote DB flexibility?

Sorry for the huge question...

I am developing a wide application that will initially target mobile clients, but will eventually target web clients as well. The core technology will be C#/.NET/EF2.0, the mobile app will be developed with Xamarin.Forms and there will be two databases: one local - SQLite - and one remote - MySQL. The SQLite one will probably have the same schema of the remote one, but will store only the user relevant records. Both will be frequently synched.

I have already defined my DB schema, my domain and my SQL queries - which required some tuning as some tables might end up storing hundred of millions of rows each year - but I'm struggling with the application layer.

I am very new to DDD design and webe/backend development. This project started as a "funny" way to learn this topics, but now I'm into releasing the mobile app - at least - on the market, after some positive feedback of many potential users.

My requirements:

1. I would like to have 100% reuse of the application layer for all the clients

2. Enough flexibility to switch DB strategy with almost no code modification. EG. I want the mobile app code to be flexible enough to switch from local only Vs remote only Vs a mixture of the two (maybe some tables won't be kept locally at all) even at runtime - For example, phone offline mode will force to use the local DB.

3. When acting remotely the queries might be a bottleneck, this is likely to happen in few years

I think the main point is I'm not really sure about what the application layer is. I know it is basically a collection of queries, but I don't really get how the clients interact with it. This point might be more clear in my next issue point.

I have different issues.

1) How to make the DB access mode fully transparent and potentially dynamic? Where this abstraction should go? My first idea was to exploit the repository pattern. So I might have one for local queries and one that would call RESTful APIs. Maybe a factory which the client will use to create the repository each time, which will decide which implementation of the repository should be created according to some parameters.

Doing this way, I will have to split all the queries to the remote DB into many REST calls - one per aggregate root as per my understand of Repositories DDD wise - which i feel is terribly bad as it might greatly increase data transfer over the net.

So is the Application layer the one to act as a gateway between local Vs remote calls? This solution seems way more complex to me...

Or, will each client have its own Application layer? And if this is the point, it means I have really no understanding of the whole DDD modeling!

2) If performance really becomes a concern how to deal with SQL query strings without breaking my architecture? As my queries embrace different aggreagate roots I think I won't be able to use my repositories.

3) One of the first things I've learnt about SQL queries is: "don't use *, but fetch what you really need" and I'm fine with it. How will I customize my queries in order to have fetch only the columns I need and maybe apply some sorting or pagination?

Let's say my Application layer has:

BannedUsersQuery()

What if I want to have another version which fetches a smaller set of columns and orders the results according to another field? I don't think that writing another query command is the best practice:

BannedUsersWithLessFieldsAndAnotherSortOrderQuery()

I realize I've very new to these kind of topics and I'm not absolutely sure not to have been written some nosenses... But it's really difficult to dig into these topics with no guidance... Hope to find some light here!