Based on the 1st chapter of the book Dependency Injection in .Net it appears a more usable dependency hierarchy of an application is that the middle tier is the master with no dependencies on the User-Interface or Data layers. This is accomplished via interfaces(or abstract classes). So the user-interface should have no dependencies besides on the middle tier(business logic/Domain library). And the Data layer(s) should depend on the business logic tier.
The reason for this is that if the database itself changes form (we move from one sql server to another, or change the database design, or the data feed moves to ISeries instead of a mainframe, or to teradata instead of a mainframe) the only thing that needs to change is the data Layer. If we change the UI around (windows forms to web) the only thing that has to change should be the UI layer). The middle tier(business logic/Domain library) should be the absolute heart of the application.
Another major reason for this is if the business logic needs to be changed the middle tier having no other dependencies should make it safer to make that change without worry for what the other moving parts are going to do.
The goal being to move this spaghetti type code:
To this clean structured layout where the UI or data access sections can be swapped out as needed:
The first chapter of the book is available online for free, and is where I read this information. The examples in it are fairly well written.