Да, мы и делаем, почти это

Грубо говоря, правило no-restricted-imports с блеклист паттерном, тогда при оверрайде конфига в каждой директории можно всё это устроить

Может кто-то по-другому делает?
А то так будет много конфигов, или конфиги будут композиться из других файлов (где эти связи  как-то описаны)

Ещё у этого правила нет возможности описать текст ошибки, именно когда паттерном указываешь блеклист, ишью открытое

Когда мы релизнем плагин для валидации структуры проекта, у меня в канале и здесь будет анонс.
Можно будет заюзать его и опираться на правила, которые рекомендует плагин.

Одна из целей плагина, это давать ссылки на документацию по методологии в тексте ошибок, чтобы разработчики сразу могли почитать

- api
- features
- lib
- pages
- processes
- shared
- ui

Стало понятно, что нужена директори shared.
Там лежит все что связано с одной сущностью, но не прибито к бизнес логике: компоненты, валидаторы, кеши, хуки, и т.д.

в features лежат маленькие бизнес кейсы без вьюхи, только логика.
blog-post-creation, user-registration
Страница может композироваться из фич и шаред модулей.

в processes лежат большие процессы, которые сидят сверху над всеми страницами. Как саги, форкаются при старте приложения и следят за жизненными циклами. Например, процесс оплаты требует 3 страниц и должен проверять может ли пользователь перейти к следующей странице, сохранена и активна ли сессия и т.д.

Все эти сущности нужны для упрощения восприятия и модификации проекта, но требуют времени на освоение.

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

Каждая такая секция раскладывает код по сложности изменений и по опасности.
Если отсортировать их по сложности изменения, то получится такой список, самый первый самый простой для изменений, последний наисложнейший:
1. ui, lib
2. shared
3. features
4. pages
5. processes

А если отсортировать по опасности изменений, то получится ровно обратный список.
Первыми будут процессы, потому что от них никто не зависит и модификация процесса может сломать только процесс. А вот модификация страниц может сломать процесс, но только его.
Но при этом при изменении ui или lib, стоит быть максимально осторожным, потому что они используются во всем проекте.

Собственно эти списки показывают какие усилия требуется сосредоточить в каждой части кода. Например, становится очевидно, что ui и lib должны быть максимально покрыты unit-тестами и документацией. А процессы и страницы должны быть покрыты e2e тестами, чтобы правильно выполнять сценарии бизнес-логики.

Также внезапно становится очевидно, как погружать новичков в архитектуру проекта и взаимосвязи: нужно выдавать задачи пытаясь идти по списку выше, от модификации и создания ui и lib, предлагая напороться на сложность их переиспользования, а дальше постепенно увеличивая бизнес-ценность переходя от shared к features и страницам с процессами, при этом разработчик будет знать как устроен проект снизу.

1 - я бы предложил еще подумать на названием папки shared. Сложно объяснить почему но не нравится. Возможно потому что уже на многих проектах используют что со словом shared и как правило там помойка. То есть есть некий неприятный шлейф(так что может это мое личное восприятие)
2 - почему из фич убрали ui слой? Часто бывают компоненты которые привязыны к конкретной модели. И эта связь как правило 1 к 1.
3 - пока не понял почему процессы это не часть фичи или же почему это не фичи. Или процесс в каком роде это то что можно описать как последоватеность страниц  в рамках какого-то одного действия ?(как пример регистрация пользователя для завершения которой нужно заполнить три формы?)

первое ощущение от этого описания что фичи тают на глазах и скоро их просто нужно будет выпилить)

1. тоже есть такое ощущение, но лучшего названия пока не удалось придумать. Которое ещё бы и точнее описывало смысл

2. потому что в данном случае фича это небольшой бизнес-кейс, а не модель. Но ограничений никто не накладывает. Можно экспортить всё что кажется правильным, но всякие реюзабельные штуки лучше выносить в shared

3. потому что процессы гораздо более сложные, нежели фичи или страницы. Если объединить процессы и фичи, то получим двойную связанность: фича знает о страницах, потому что ей нужно контроллировать несколько страниц, и страница импортит что-то из фичи. Это всё порождает циклические зависимости

по этому описанию “Там лежит все что связано с одной сущностью, но не прибито к бизнес логике: компоненты, валидаторы, кеши, хуки, и т.д.” это похоже на entities

А ты уже создал организацию feature slices ?
А то мне вон приглос пришёл на почту, правда от другого чувака )

А ты уже создал организацию feature slices ?
А то мне вон приглос пришёл на почту, правда от другого чувака )

Организация да, не переживай

оууу.. даже уже организация? ждать какой-то анонс?)

Всем привет. Когда кто-то говорит о feature-slices с каким эмодзи у вас ассоциируется идея и паттерн?