Можно пример того, как это выглядит?

готового примера нет. Пока только мысли. Сейчас пробую внердрить на проекте

Почему такие мысли пришли?

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

Проанализоровав почему они возникают, я пришел к тому что причина именно в фичах-сущностях на подобии users/ posts/
В  кинге “Чиста Архитектура” Мартина есть такой термин как use-cases, которые мне сразу показались в чем то похожими на фичи. Но по Мартину это как раз способы использования данных а не сами данные. А слой данных лежит отдельно.

Я пока не вижу как вся предложеная “чистая архитектура” Мартина ложится на фронт, но именно вот это разделение мне показалось интересным так как позволяет, как мне кажется, разрешить эти противоречия.

В целом, я понял, но что делать уже сейчас :D

А чего фотки удаляются

И ссылки тоже

Местный бот, ОЧЕНЬ агрессивный

> Я пока не вижу как вся предложеная “чистая архитектура” Мартина ложится на фронт

Клинкод — никак

А почему фичи не могут импортировать другие ? Кем / чем это запрещено ?

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

реализуются они с помощью интеракторов / cqrs | чего угодно ещё

Все «фичи» в семействах клин-архитектур находятся в домене. Это доменоцентричная архитектура, смысл которой в том, чтобы сделать независимое, масштабируемое и переносимое ядро благодаря таким понятиям, как порты и адаптеры (завязка на абстракции и выставление абстракций наружу)

К тому же, понятие фронтендовой «фичи» отсутствует в клин-архитектурах как таковое вообще. Чаще всего семейство клин архитектур (а их около десятка) неразрывно идёт с ддд, что обычно сильно сложнее фронтовых фич

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

например, интернет магазин. в нём можно выделить такие баунд-контексты
1) баунд-контекст юзера (туда войдёт сущность юзера и связанные с ним настройки, например)
2) баунд-контекст покупок (туда войдут сущности покупок, товаров, возможно - корзины. почему возможно ? Видел в некоторых системах разделение корзины в отдельный баунд-контекст)

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

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

и так со всем (т.е. баунд-контекст корзины берёт что-то из юзера, что-то из контекста товаров)

__________________
ну, это если всё совсем грубо описывать

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

таким образом, архитектура проекта из feature slices превратиться в features imports hell уже года через пол очень интенсивной разработки

гораздо проще не пытаться натянуть сову на глобус (клин-архитектуру и все производные на жс фронтенд) в том виде, в котором их описывает фаулер, роберт мартин и кто угодно ещё, а просто использовать некоторые принципы из общих архитектурных практик (solid + пару других вещей)

Те же практики из книжки клин архитекчур

Только не про конечную архитектуру

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


давай посмотрим на типичное приложение в связке с react - redux - redux-saga / thunk - mobx: да там инфраструктура вызывается прямо в кишках приложения, во всех описаниях бл и бизнес-процессов

мы ведь напрямую дёргаем какие-то аксиосы, фетчеры, свои собственные абстракции для работы с локалсораджем, сессиями, куками и тд / тп. это всё инфраструктурный код. Его можно спрятать в набор абстракций, хоть это будет и не совсем "полноценный" интерфейс, но какой ценой ? Ценой дикого переусложнения ВСЕГО

не говоря о том, что нам, как правило, нет смысла вводить отдельные абстракции, типа "адаптера, презентера, интерактора / юзкейса" и тд / тп


короче, мой посыл в чём - эти архитектуры очень крутые, лично сам я в них влюбился сразу и практикую их уже 5 лет как на бэке, так и на фронте (не жсном), но на ЖС фронтенд они не натягиваемы от слова совсем

++

да, я об этом и говорю. он в клин архитектуре половину книги описывает общие практики

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