Я думаю, что это зависит от конкретного проекта.
Например, если разные бизнес-домены полностью независимы друг от друга, я бы организовал их по бизнес-доменам.
Но если между бизнес-доменами существует общий код, или, скорее, бизнес-домены - это разные варианты одной и той же кодовой базы, то представляется логичным организовать их по техническим областям . И если вы используете какой-либо объектно-ориентированный язык, то, вероятно, вы можете создать подклассы ваших общих контроллеров, моделей и т. Д. В своих бизнес-файлах, чтобы сделать их тоньше.
Существует также (золотая) середина между ними - раздели общий код в его собственный домен и используй его в других доменах. Это дает вам интуитивно понятное расположение, но позволяет использовать общий код для бизнес-доменов.
Domain1 # This domain changes bits of standard MVC code
controllers
models
views
Domain2 # this domain only modifies views, all else is standard
views
Shared # Here is the better part of code base
controllers
models
views
PS. Я думаю, что большинство фреймворков организовано по техническим областям только потому, что они ожидают, что вы объединяете разные бизнес-домены в один проект, только если у вас есть общий код, и в противном случае вы создадите отдельные проекты.
РЕДАКТИРОВАТЬ:
Например, предположим, что есть веб-приложение, которое обрабатывает склад компании. В общей форме это может относиться ко многим компаниям, но у каждой из них могут быть некоторые особенности, которые не встречаются и запрещают их покупать. Например, один из них развернул планшеты на вилочные погрузчики и нуждается в специальном представлении для них, в то время как другой хочет организовать элементы в три уровня вместо по умолчанию двух.
Конечно, вы можете раскошелиться на проект для каждой из этих компаний. Но если структура / язык позволяет, вы можете использовать подклассы или плагины и т. Д., Чтобы настроить отдельные части общего проекта в соответствии с потребностями каждого клиента и организовать их в макетах Business Domain.
Например, если общий проект экспортирует в JSON только сам элемент, Domain1 может создать подкласс контроллера и заставить его экспортировать также недавние проблемы с доставкой.
И если позже вы обнаружите, что Domain1 имеет компонент, который также подходит для Domain2, вы можете извлечь его общую версию в Shared.
Как вы сказали, многие фреймворки организованы по техническим областям, и это то, что я использовал на данный момент, просто потому, что мой выбор FW делает это проще. Но с небольшим (или большим) количеством консистентной смазки, я думаю, я мог бы также переписать пути включения для поддержки макета Business Domain.