На features/slices потом надо будет перенести

А пока так 🤷‍♂️

я вообще это еще и за фасадом скрываю

контроллер

в methods - эффекты
в scenarios - описание взаимодействия (все это импортится в init как сайд эффекты)
в shared  - всякие хелперы и прочая хурма  (все то, что _помогает_ описывать бизнес логику, но ею не является)
в state - сторы
в index выносятся все сторы и эффекты и ивенты, но не все, естесвенно. Это фасад

вот с раскрытыми папочками

пол года жизни потратил на то, чтобы к этому прийти

слишком много сущностей в добавок к юнитам

вообще цель такого подхода одна - облегчить рефакторинг

вот это меня как раз не волнует

Каждая директория обязательна?

везде одни и те же лица

для меня да

моя цель - максимально снизить стоимость внесения изменений и цену будущего рефакторинга

Как помогает такой подход?

Хм, заменил на хендлеры - все равно не ререндерит

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

я уже не говорю о том, что вместо двух уровней доступа получается 3: приватные переменные, протектед (которые нельзя даватть использовать, но которые могут участвовать в тестировании) и публичные

у меня проект поверх grpc-web и рефакторинг был отчасти это постоянные изменения в контрактах из-за чего приходилось кучу всего перелопачивать

и разграничение зон ответсвенности, инкапсуляция - это именно то, что позволило с каждой такой правкой вносить меньше изменений

тот же подход через index и в api слое:
каждая папка - это название процедуры из контракта (кроме messages - там лежат конверторы)

С помощью какой конвенции защищаешься от циклических?

каждая процедура это хендлер (адаптер), это типы и это index - где оборачивается все в эффект