Смотрю видео с митапа "Фреймворки и инструменты PHP", доклад @samdark про Yii2 и Yii3.

https://youtu.be/MuVMe7oMoyM?t=1170

Рассказывается с 19:30 про то что структура Yii2 приложений с группировкой "по типу" плохо подходит для средних и сложных проектов. "По типу", значит все контроллеры в одном месте, все модельки во втором, все вьюшки в третьем и т.д.

Я сам столкнулся с этой проблемой, прошёл через осознание и постепенный уход от этой структуры в сторону модульности. Под влиянием Дмитрия Елисеева и Дмитрия Дерепко )

Теперь весь используемый вместе код стараюсь группировать и держать рядышком, в одной папке. Бить приложение на части по модулям. Дополнительно слежу за тем, чтобы внутри модуля не было слишком много обращений к внешнему коду, и чтобы к самому модулю обращения были в минимальное количество точек.

Этот подход действительно работает и ускоряет работу, упрощает изменения. Работая над конкретной задачей мне теперь вообще почти не приходится вылезать за пределы папки модуля. Снизилось количество конфликтов с прочим кодом, который меняется параллельно другими разработчиками.

В общем, рекомендую всем )

Кстати в Laravel то же структурирование "по типу" что и в Yii2 )

Вот. Надо issue создать если ещё не создали )

уже тоже к этому пришел. когда в models стопицот моделек. уже даже искать нужную сложно

в шторме сделать категории и отображать дерево проекта с возможностью переключения  папки/категории

Такой пример, если в одном модуле сущность - Пользователь, а в другом сущность - Автор. Это 2 разных класса, которые маппим на одну таблицу?

И что это даст когда 200 моделек в одной папке? ))

Вот это даст.

Это называется бардак )

По таблицам. Идеально для модуля делать свои таблицы и свои классы маппинга данных и сервисов для работы с этими данными. Чтобы наружу ни одна таблица не торчала в принципе, только абстрактное API модуля в виде специальных публичных классов и методов. Я подобные классы складываю внутри модуля в папку Contracts, можно и Api назвать (апи модуля по отношению к внешнему коду), но API нынче слишком широко трактуемое понятие, путаница будет, поэтому Contracts.

Если нет возможности или времени, если слишком тяжело разделить таблицы по модулям, то как промежуточный этап можно делать обёртки.

Пример из жизни. Есть в проекте таблицы users, profiles. При этом в модуле я не хочу завязываться ни на класс User, ни на класс Profile. Я делаю внутри модуля класс Person. Всё обращение внутри модуля за информацией, которая требуется из User или Profile, происходит только к классу Person, который "внутри себя" проксирует и выдаёт необходимую информацию из таблиц "users" и "profiles".

С одной стороны, некоторая связь с таблицами осталась. С другой стороны, я получаю хороший профит в том, что при изменении User или Profile мне не нужно лазить по всему модулю, а только нужно исправить пару строк в Person.

По сути, я провожу архитектурную границу, разделяя код вне модуля и внутри модуля, за счёт этого повышаю устойчивость к внешним изменениям.

И это испробовано ) Три года назад ) Сгруппируй нормально чтобы было
calls\
calls\models
calls\controllers

и ощутишь разницу )

Хотя кому я говорю, у вас там композером ещё пользоваться не научились в команде...

Это даст вывод файлов по категории. Причём один файл может принадлежать нескольким категориям.

Тоже задумываюсь над таким переходом... А если есть общий какой-то код, как его располагать?

А почему Вы считаете, что модули должны объединять, например, звонки и это будет нормально?
В этом проекте и модули есть, но сгруппированы они совсем по другому пригципу - по функциональному.

Если он реально общий то папочку Components или Helpers, если классы мелкие, а если это наборы классов то это будут самостоятельные модули.

О нет, папочка названа master. Как мерзко!

))

Сделаю проект назову главную папку nigga )

Это почему?

Ещё очень хорошо такой кейс разбирал Валентин Удальцов, к сожалению не видео и не статья, а просто сообщения в чате "Пыхтелка" ) https://t.me/phpyhtelka/13693

Спасибо, надо обдумать