There should be a clear decision made from the get go wether you want DDD or n-tier. They have fundamental differences. Do your entities have public setters? If so, chances are you're already violating aggregate root integrity. n-tier focuses on data centric aspects whereas DDD focuses on behavioural ones. 

Anyway, a DAL is supposed to be a Data Access Layer. Where that data comes from (db, flat file, web service) should not be a factor. You could have an abstraction of the DAL (for example, expose interfaces) and switch in different implementations of the DAL (from db or web service). You don't need a further abstraction of a repository on top of the DAL. In most n-tier scenarios, a repository is the DAL and vice versa. Otherwise, most of your "layers" would have methods that look like this:

void DoSomething(int foo)
{
    _lowerLayerInstance.DoSomething(foo);
} 

If all an abstraction does is delegate to another abstraction, then consider whether or not you really need it.