@fes0r спасибо за много текста)

Если репы юзаются в аппликейшене, то интерфейсы реп я бы клал именно в аппликейшн

О, тоже такие мысли возникали, не такая уж дичь оказывается)

Клади туда, где удобнее и что будет логичнее для тебя. Раз ты это делаешь для
“Ну удобно с точки зрения организации кода”

эт если они ток там юзаются. Смысл в направлении зависимостей.

Ну в доменных сервисах есть вероятность захотеть их юзать, но я их делаю чистыми

ну у меня мысль какая.... у тебя есть "слои для разделения этапов в потоке данных, и есть модули для структуры кода и декомпозиции". Мне так жить проще. Проще объяснять почему у слоев те или иные ограничения, почему нужен application layer для оркестрации потоком данных, почему есть домен который по возможности остается чистым и т.д. и почему в целом эти "слои" не мэпятся на папки (потому что на папки мэпятся модули)

а какие нибудь совместные коддинг сессии не проводите?) (участники канала)

не очень понял, про модули для структуры 😟 на моем не сильно высоком уровне, я больше думал "а возьму юзкейсы из аппликейшена положу в папку где агрегаты, во и доменные сервисы.. типа ничего страшного, сам я понимаю, их различие, и ладно + кроме юзкейсов у меня в папке аппликейшена ТОЛЬКО интерфейсы - реп, гейтвеев, комманд для юзкейсов"

типа глобально имею 2 уровня, прям инфраструктура-инфраструктура и "доменная" часть (хоть юзкейсы это аппликейшном считается)
типа эти 2 уровня (инфраструктура и "домен") прям сильно и легко различаются, а вот взять отдельные Domain и Application - там можно потупить и размазать логику как-то не очень хорошо между ними

по итогу у меня конечно папки Infrastucture, Application и Domain (аппликейшн и домен четко разделены, для себя поставил правило - домен не юзает ничего, если в сервисе репа нужна - повод подумать почему и как сделать без зависимости), хотя есть подвижки в сторону "а можно вообще-то по-разному делать и стоит подумать как и почему"

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

мне просто так проще... слои все еще полезны, но не влияют на структуру проекта и не отвлекают от главного (зависимости модулей)

Вроде понял, вроде даже логично) для меня слои - в первую очередь про направление зависимостей, типа 3 папки есть и четко понятно куда стрелочки, потом уже "что где должно быть", нет в домене интерфейсов реп - это значит в домене репы юзать нельзя и нечего думать куда что класть, есть более важные для обдумывания вещи

Но вот что на данный момент для себя придумал про папки - папки можно как угодно делать, главное чтоб системность в этом была + чтоб папки помогали по проекту лазить эффективно

ну вот мне слои для зависимостей вообще не помогают. А вот для направления потока данных - почему бы нет. Хотя может наоборот будет путать людей. Снимаю с себя ответственность)

Разносить слои по папкам нужно когда оси изменений проходят по слоям, например к одному домену есть несколько апликейшнов. У меня в одной из компаний например было 5 app на один домен в монолите, и там это серьёзно снижало стоимость изменений. Сейчас у меня 1 к 1, и в таком случае намного логичнее держать все слои кроме инфры внутри каждого модуля на одном уровне. Однако у этого есть проблема технического характера, нет тривиальных, а главное удобных инструментов которыми можно сказать мол "все сервисы в какой бы папке они не лежали могут использовать только домен только из папок на одном уровне и вложенных относительно сервиса" или что-то подобное.

Причем в случае 1 к 5 домен не превращается в не модульный мусор как ни странно. А когда 1 к 1 помойка в каждом из слоёв ещё та.

Замечу так же, что i/o всегда должен иметь сквозные ограничения, и мы скорее всего хотим их материализовать как можно более явно, так что вы скорее всего хотите чтобы в один клик можно было посмотреть всё что делает с фс ваше приложение. И положить это в одном месте это один из тривиальных вариантов.

вопрос понимания "удобство". Для PHP: deptrac и nocolor

ну да, я про них, в js это dependency-cruiser и eslint-че-то-там