но в целом даже "направление зависимостей" стоит выстраивать не на основе слоев, а на основе стабильности зависимостей. В том плане что если у тебя есть модуль А и он зависит от Б - если Б меняется существенно реже чем А то все хорошо.

причем еще важно какие изменения нас интересуют - нам важна стабильность контрактов и поведения. Детали реализации могут меняться

Достаточно просто что бы у тебя эти слои в разных модулях лежали - так ведь модуль = папка, разве не так?

а как можно изначально понять, что модуль А реже меняется чем модуль Б? По-сути это знание приходит в процессе разработки.

а файлы что?

а классы?)

если модуль состоит из одного класса, тогда да 🙂

а у тебя не так? в 99% ситуаций у тебя Psr-4 этого требует

в этом загвозка. Что бы все было хорошо надо знать как будет дальше. Потому про все эти принципы обычно рассказывают после рефакторинга. Часто можно предсказать че как будет + есть whole value концепция которая позволяет тебе бизнес логику писать вообще без зависимостей (и в целом целью надо ставить в первую очередь избежать зависимостей а уже если они получаются можно про направления оных думать)

ну да, в идеале если у тебя вся логика на осное whole value, то и зависимостей не особо много 🙂

я вот пробовал контроллеры тоже считать за кусок фичи, но у меня получается, что контроллеры скорее либо агрегируют данные (какие-то запросы на чтение) либо раскидывают(например сочетание crud + какое-то бизнес-нагруженное действие) данные при записи. То есть они частенько юзают 2 фичи, поэтому всё равно не могут быть отнесены только к какой-то одной.

надо дальше пытаться декомпозировать наверное 🤔

а тут сложно на самом деле... с одной стороны это части фичи, в том плане что они там за логику какую отвечают. С другой стороны - есть Backend for frontend. Ну то есть желательно все ж под конкретных клиентов сверху свои адаптеры делать

ну то есть... грубо говоря есть у тебя скажем "фича" - посмотреть список заказов. И есть два клиента - бэкофис какой где списки заказов и скажем твои текущие заказы. По хорошему там свои представления данных, свои пермишены и т.д. и лучше это держать раздельно.

Мол контроллеры для бэкофиса и контроллеры для пользователя. Они могут сходить в один сервис и получить список айдишек + минимальные детали, потом долепить композицией сверху данных из других сервисов и т.д. В итоге они как бы уже не совсем "внутри" какого-то bounded context.

но есть и простые кейсы где в целом можно контроллеры и туда запихнуть..

а можно наоборот - делать фичу "список заказа" которая как бы вообще рид моделька которую другие сервисы "наполняют". Тут много всякого можно придумывать

вот я из разных клиентов как раз пробовал делать, поэтому щас вообще разглядываю папочки  вот такие
Adapters (контроллеры под разных клиентов)
- ClientApi
- AdminApi
Model (тут условно энтити)
Infrastructure просто тулы либы и т.п.
Сверху под клиентов адаптеры хочется, но... Тогда адаптеров по 2 штуки получается. Те которые сверху, агрегируют и вот это всё и те которые снизу - которые под фичу. Как-то оверхед дофига для простых проектов.

я под такую композицию для клиентов чтения (апи, интеграции) похожую на твою тулзу запилил, но у меня она не зависит от нормалайзера симфони, на входе массив - на выходе массив дополненный. Дальше уже как хочешь - можно либо сразу массив сериализовать на фронт либо смаппить тем же нормалайзером на на объект.
Мне даже кажется, что лучше чем у тебя (но это неточно)

и промисколлекшен не торчит :D
Но есть и свои костыли

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