Почему в проекте файлы/классы группируют по слоям(ModelLayer/UILayer и т.п.)?

MVC тут не при чём в моём вопросе, это просто легковесный пример.

В том и вопрос, мне тоже кажется удобнее группировать как вы написали. Но мне кажется не спроста группируют наоборот. Должны же быть причины почему так делают почти все.

Denis Morozov: MVC тут **причем**. Это стандартная разбивка для MVC проектов, которую вы найдете в любой книжке. От сюда все ее и используют. Пока в проекте десяток моделей и контроллеров - никто не замечает проблем, но как только проект начинает расти - вся эта мешанина классов начинает только мешать, и в итоге многие приходят к разбивке как я написал выше.

Denormalization: Про MVC это всё понятно. Тем не менее, я не видел ни одного проекта где разбивка была бы отличной от той что я описал. Сколько работал со многими людьми, но впервые слышу такое: "в итоге многие приходят к разбивке как я написал выше". Сколько видел проектов все упорно разбивают так как я описал в вопросе

Denis Morozov: большие проекты сложно переписывать, поэтому всё оставляют как было и продолжают **жрать** кактус. Так же зависит от языка\фреймворка на котором все это пишется. Многие языки\фреймворки просто не позволят создать иную структуру приложения.
В общем виде это бессмысленный вопрос, так как каждый делает так, как считает удобным для себя. Я для себя решил что моя версия разбивки удобнее, и все новые проекты делаю с такой разбивкой.

Denormalization: переписывать же ничего не надо, переколбасить структуру директорий. тут есть проблема именно с переколбашиванием структуры директорий связанная с VCS(git не умеет файлы перемещать и потеряет историю, а меркуриал умеет). проблемы что надо что-то переписывать я не вижу

Denis Morozov: реализация автолоадера/DI контейнера может не позволить перепилить структуру директорий.
Новые namespaces, которые необходимо прописать везде где они могут использоваться.
В итоге все упирается в платформу с помощью которой реализуется проект. Попробуйте переписать проект без namespaces и с кривым автолоадером, который имеет жесткую привязку к структуре приложения(я говорю про PHP).

Нету **правильного** и **не правильного** способа разбивки проектов. Это все субъективно и базируется лишь на собственном опыте.
Я видел проекты где можно обычной структурой: Controllers, Models, View, а там городили такие ужасы, что проект просто нереально было поддерживать из-за кол-ва абстракций и наследования.

Denormalization: Вы уходите в сторону от моего вопроса =)

Denis Morozov: я ответил на ваш вопрос: "Это все субъективно и базируется лишь на собственном опыте". Ваша разбивка подходит для небольших проектов, но не для крупных. В тоже время в любой книжке вы найдете пример именно с вашей структурой, так как ее упорно копируют из книжки в книжку.

Denormalization: Вы не поняли вопроса

Denis Morozov: Вопрос я вижу только один: "Все яро структурируют именно так, и я подумал может есть веская причина так делать?".
И ответ на него выше. Нету веской причины, просто все учились делать так, и продолжают делать.

ИМХО, от такого подхода нужно отказываться. Это из интернет-примеров повылазило такое.

мне подсказал умный человек одну вескую причину разбивать именно так. например у нас в model layer две модели и в controlers layer пусть будет 2 контроллера. тогда если контроллер1 зависит от обеих моделей, что очень вероятно, то только такая разбивка подходит

Разбивайте все по модулям, каждый отвечает за какое-то решение, и внутри уже делите по слоям, как хотите

уже разбито по модулям

Представьте что у вас 8000 классов. Вы их в 3 папки будете засовывать?

нет =)

Denis Morozov: тогда скорее всего у вас в одном модуле должно быть 2 контроллера и 2 модели. В чем проблема? Остальные 30 контроллеров раскидываете по другим модулям. Это простое решение, в лоб.
Модуль это не значит: 1с контроллер 1 модель 1 вью.

Можно еще кучу вариантов придумать:
Например, выделить такие глобальные модели (например юзер) в отдельный модуль.
Еще например, настроить ваш сборщик (Maven, Grunt, Gulp) чтобы если вам одна и та же модель нужна в 10 модулях - пусть он ее копирует при сборке.
Будет чтото типа :
src
-- module1
---- controller1
-- module2
---- controller2
-- globalModel
---- globalModel1

build
-- module1
---- controller1
---- globalModel1 // это сюда сборщик закинул
-- module2
---- controller2
---- globalModel1 // это сюда сборщик закинул

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Было бы желание, а решение найти не проблема :))

Зависит от возможностей вашего инструментария. Но я проблемы, честно говоря не вижу вообще :)