Привет, автор. Вот мои мысли по этому поводу:
1. Понимание паттернов программирования приходит только с опытом. Чтение одной лишь книги, без практики, практически ничего вам не даст. Материал быстро забудется. Лично я прочитал примерно половину книги, после чего пришлось её на время отложить. Как я и говорил - без тренировки на примерах материал быстро забылся. Вновь вспоминаться он стал при чтении книги "Принципы, паттерны и методики гибкой разработки на языке c#". В книге достаточно много подробных примеров, и именно после их выполнения я стал осознавать суть некоторых паттернов.
Разумеется нельзя считать, что паттерн - это какое-либо строгое правило. Часть паттернов мы реализуем сами ещё до прочтения каких-либо книг. Паттерн - это возможное и удобное решение, которое можно применить для решения какой-либо задачи. Не надо пытаться заучить паттерны или вставлять их везде, где можно. Нужно просто писать как можно больше кода, тогда уже автоматически начинаешь видеть ситуации, где можно применить паттерн.
2. По-поводу слабой связанности. Во всех книгах, разумеется, пишут, что слабая связанность - это хорошо. Но на самом деле такая архитектура не всегда оправдана, и специалисты в области разработки ПО об этом периодически напоминают. На практике это означает то, что не нужно везде применять интерфейсы только потому, что можно это делать. Если вы уверены, что ваши классы вряд ли будут когда-либо заменены другими, то лично я считаю, что они могут быть смело использованы друг-другом без принципа инверсии зависимостей. Ну и вопрос к модульному тестированию. Разумеется сильная связанность мешает модульному тестированию, но если вы не планируете его проводить, то быть может и не стоит строить избыточные абстракции.
Лично я также считаю, что вышесказанной в меньшей степени справедливо для прикладных и вэб-приложений (где действительно важна модульность и тестировании), и в большей степени справедливо для игровых приложений. Лично я вообще с трудом представляю игру, в которой каждый игровой объект (танк, самолёт например) будет реализовывать интерфейс, чтобы теоретически когда-нибудь мы заменили танк на био-робота. Но это так, лирика.
3. По-поводу повторного использования. Один мой товарищ - senior developer, работавший в серьёзных организациях, говорит, что повторное использование кода - это миф. Лично я повторно использовал разве что какие-нибудь вспомогательные функции. Ну или в лучшем случае несколько классов и интерфейсов для поддержки модульности. На мой взгляд, говорить о том, что можно взять и перенести из проекта в проект всю архитектуру особо не приходится.
4. По-поводу контроллеров. Насколько я понимаю (опыт в разработке небольшой) основной смысл делать контроллеры зависимыми от интерфейсов только в том, чтобы тестировать эти контроллеры (хотя я не совсем понимаю зачем). Контроллер - это действительно такая вещь, которая с большой вероятностью будет использоваться только на конкретном сайте. Также этот контроллер будет завязан на какой-то интерфейс, предоставляющий бизнес-логику. Опять же вероятность, что один класс бизнес-логики будет заменён другим классом с такими же методами - стремится к нулю, особенно если учитывать то, что класс бизнес-логики зависит от интерфейса, который предоставляет методы получения данных. (если вы хотите изменить способ получения данных - вы изменяете, К примеру, класс репозитория, бизнес логика остаётся той же). В связи с этим я вижу пока только одну причину завязывать контроллеры на интерфейсы, а не конкретные классы бизнес-логики - это тестирование. Вы стабите интерфейс бизнес-логики и тестируете контроллер независимо от всех остальных модулей. Если не прав, поправьте, конечно.

Да ладно, такое ощущение, что тролли не только задают, но и отвечают. Как так: вы знаете С++, но не знаете как делать игры? Как загружать изображения в память знаете? Как писать классы и создавать объекты знаете? Как наладить взаимодействие объектов тоже знаете? Тогда в чём вопрос вообще?
Если вы не понимаете как именно работать с графикой, то подсказываю: никто не гонит использовать нативный Direct3D. Берите любой подходящий фреймворк и в путь. Для C++ могу посоветовать, Например, HGE. Я сам с него начинал. Он уже не поддерживается, насколько я знаю, но форум жив, а энтузиасты потихоньку его допиливают. Примеры есть, да и сам по себе он достаточно простой. С его помощью вы сможете загружать изображения (в том числе анимированные), а так же манипулировать ими. Для создания 2Д игры самое то. В общем посмотрите примеры и сами попробуйте.
Также, смотрю, проскакивают ответы насчёт того, чтобы делать сразу трёхмерную игру, да ещё и с физикой. Да блин, начните с простого. Сделайте. как тут уже писали, кнопку с поведением, или ещё лучше, напишите тетрис или смейку. Потом уже разберётесь как что работает. Без знания основ вообще не вижу смысла хвататься сразу за 3д.
И игра - это не обязательно физика. Не надо сразу ломиться читать алгебру и начинать писать свой физический движок. Изучайте всё по мере надобности.

Тема достаточно глубокая, лично я сейчас сам её изучаю. Пока что просто подкину вам нужную ссылку:
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. О том что это - поищите в поисковике. Надеюсь ответ был полезен.