Как правильнос построить N-Tier/N-Layer архитектуру для ASP.NET проекта?
Тема достаточно глубокая, лично я сейчас сам её изучаю. Пока что просто подкину вам нужную ссылку: 
blog.byndyu.ru/2014/05/blog-post.html
Почитайте, у Александра там ещё много чего интересного написано по этой теме.
Если говорить конкретно по вашему сообщению, то в целом вы всё описываете правильно. Т.е. у вас может быть слой DAL для доступа к базе данных и получения объектов. При этом DAL не содержит бизнес-логики, он только возвращает объекты. Причём списки объектов желательно возвращать как IEnumerable, а не IQueryable.
Далее, как вы правильно сказали, есть слой бизнес-логики. Опять же, как правильно было замечено, слой бизнес-логики хранит ссылку на интерфейс DAL и обращается к нему для получения объектов. Конкретный DAL задаётся через DI.
Насчёт обращения к DAL из контроллера - я бы рекоммендовал всё-таки обратиться через сервис. Вообще я задавал Александру почти точно такой же вопрос - что если мне требуется просто получить список объектов из DAL. Он дал мне ссылку на эту статью blog.byndyu.ru/2011/08/repository.html Почитайте, там как раз об этом.
По-поводу того, в каких сборках правильнее хранить интерфейсы - я, к сожалению, сам пока точно не знаю, так как не прочитал ещё достаточно литературы.
И в финале скажу, что сам Александр рекоммендует по-возможности использовать не сервисные слои, а CQRS. О том что это - поищите в поисковике. Надеюсь ответ был полезен.
Я бы все таки посоветовал постараться  понять в чем отличие многозвенной архитектуры приложений от разбивки кода на слои, а потом уже к написанию кода переходить.