Вопрос: На чём лучше прокачивать архитектурный навык разработки моделей предметной области и принципов DDD вообще?

Лучший ответ: Любой фреймворк с инверсией зависимостей подойдет. На Symfony и Yii2 точно можно сделать. На русскоязычном форуме Yii по теме DDD очень много обсуждений. Но если не увидели единого согласия по DDD, то скорее всего не читали книгу Эванса или Вернона. Если так, то лучше начать с кого-нибудь из них.
Многоуровневая архитектура рассказывает нам о слоях presentation, application, domain и infrastructure. С однонаправленным потоком данных. Нижестоящий слой, никогда не должен вызывать вышестоящий. Это значит, что к примеру можно выбросить presentation слой и не придется ничего изменять в оставшихся 3.
Фактически выходит, что в любой момент можно выбросить фреймворк и заменить другим, так как это presentation layer в многоуровневой архитектуре. Можно даже сначала  написать application/domain, проверить их юнит-тестами, а только потом уже задуматься о  фреймворке. Application/domain слои никогда ни при каких обстоятельствах не должны вызывать методы фреймворка. Контроллеры фреймворка работают с доменной моделью, через вызовы методов application layer.
Соответственно, при миграции на другой фреймворк, всё что потребуется, это переписать контроллеры (методы очень простые 1-5 строк) и реализации классов в infrastructure layer если вы завязывали их на фреймворк. Хотя лично я бы, не советовал этого делать. Лучше найти/написать отдельные библиотеки/компоненты под инфраструктурный слой, тем самым облегчив себе жизнь в будущем, когда фреймворк умрет или при очередном релизе мажорной версии.
Symfony под DDD наилучший выбор, он компонентный, можно подтянуть только то, что нужно. С другой стороны Yii2, он монолитный и вы затяните Active Record и кучу всего еще, чем не будете пользоваться, но джуниор придет и обязательно понавызывает AR или чего-нибудь еще в application/domain слоях, чего вы явно не ожидаете. Поэтому в случае с Yii2 нужен будет тотальный контроль. :)
Про Laravel не пишу ничего, так как не работал с ним. Но судя по беглому просмотру  документации, никаких проблем сделать на нем DDD также нет.

Худший ответ: Как упоминают авторы других ответов, очень важно разделять задачу на части со сфокусированными зонами ответственности. Важно держать под контролем их взаимопроникновение, определять, кто от кого должен зависеть, а кто нет. И каким образом всё это можно согласовать с необходимыми характеристиками разрабатываемой системы. Иначе говоря, древний принцип "Разделяй и властвуй" и его IT-интерпретация "Single Responsibility Principle" - наше всё.
В частности, решая задачу, вписывающуюся в область применения DDD, мы должны выделить ядро, которое моделирует определённый ограниченный контекст. Вероятнее всего, также мы должны подумать о разделении обработки команд и запросов. Потому что команды означают изменение состояния предметной области, всякие валидации, транзакции, консистентность и прочее. Запросы же означают иное представление данных, эффективный доступ на чтение, инвалидацию кешей и т.д., и т.п.
Так от чего же должно зависеть DDD-ядро? Должно ли оно зависеть от конкретной реализации БД или ORM? От того, какие таблицы присутствуют в Вашей реляционной СУБД?
 Или от протокола HTTP? Или, допустим, от конкретной файловой системы? Эти вопросы являются скорее риторическими. Поиск ответов на эти вопросы, а также подхода к тестированию DDD-ядра привели к описанию Hexagonal Architecture (известной также под именем Ports And Adapters). Очень советую узнать подробности и поискать, как Вы могли бы сделать такое доступными Вам средствами PHP.
Пара других наводящих вопросов: должна ли работа с HTTP как-либо быть связана с взаимодействием с БД? Какой из компонентов системы должен знать параметры подключения к БД? Должны ли совпадать жизненные циклы ответа на HTTP-запрос и агрегатов в DDD-ядре? Должен ли HTTP-фреймворк диктовать Вам организацию DDD-ядра? Должен ли ORM-фреймворк диктовать Вам организацию DDD-ядра? А кто всё-таки должен?
Буду ждать Ваших комментариев.