Слайсы и сегменты

Слайсы

Слайсы - это второй уровень в организационной иерархии Feature-Sliced Design. Их основное назначение - группировать код по его значению для продукта, бизнеса или просто приложения.

Имена слайсов не стандартизированы, поскольку они напрямую определяются бизнес-областью вашего приложения. Например, фотогалерея может иметь слайсы photo, create-album, gallery-page. Для социальной сети потребуются другие слайсы, например, post, add-user-to-friends, news-feed.

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

Слои Shared и App не содержат слайсов. Это связано с тем, что Shared не должен содержать никакой бизнес-логики, следовательно, не имеет значения для продукта, а App должен содержать только код, относящийся ко всему приложению, поэтому в разбиении нет необходимости.

Правило публичного API для слайсов

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

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

Модули вне этого слайса/сегмента могут ссылаться только на публичный API, а не на внутреннюю файловую структуру этого слайса/сегмента.

Подробнее о причинах требования публичных API и лучших практиках их создания читайте в справочнике о публичных API.

Сегменты

Сегменты - это третий и последний уровень в организационной иерархии, их цель - группировать код по его технической природе.

Существует несколько стандартизированных названий сегментов:

• ui - компоненты пользовательского интерфейса, функции форматирования данных
• model - бизнес-логика и хранилища данных, функции для обработки этих данных
• lib - вспомогательный инфраструктурный код
• api - взаимодействие с внешними API, API-методы бэкенда

Другие сегменты допускаются, но должны создаваться только по необходимости. Наиболее распространенными местами для других сегментов являются слои App и Shared, где срезы не имеют смысла.

Примеры

Layer	ui	model	lib	api
Shared	UI-библиотека	Обычно не используется	Утилитарные модули из нескольких связанных файлов. Если вам нужны индивидуальные вспомогательные функции, обратите внимание на библиотеки утилит, например, lodash-es.	Примитивный API-клиент с дополнительными функциями, такими как аутентификация или кэширование.
Entities	Скелет бизнес-сущности со слотами для интерактивных элементов	Хранилище объектов этой сущности, а также функции для обработки этих объектов. Этот сегмент лучше всего подходит для хранения данных с сервера. Если вы используете TanStack Query или другие методы неявного хранения, вы можете опустить этот сегмент.	Функции над объектами этой сущности, не связанные с хранением данных	API-методы, использующие API-клиент из Shared для упрощения коммуникации с бэкендом
Features	Интерактивные элементы, позволяющие пользователям использовать эту функцию	Бизнес-логика и хранилище инфраструктурных данных, если требуется (например, текущая тема приложения). Здесь лежит код, который непосредственно создает пользу для пользователя	Инфраструктурный код, который позволяет сегменту model более кратко описать бизнес-логику	API-методы, представляющие эту функцию на бэкенде. Может объединять API-методы из Entities.
Widgets	Композиция Entities и Features в самодостаточные блоки интерфейса. Также может содержать ограничители ошибок и состояния загрузки.	Хранилище инфраструктурных данных, если требуется	Не-бизнес-взаимодействия (например, жесты) и прочий код, необходимый для функционирования этого блока на странице	Обычно не используется, но может содержать загрузчики данных в контексте вложенного роутинга (например, Remix)
Pages	Композиция Entities, Features и Widgets в полноценные страницы. Также может содержать ограничители ошибок и состояния загрузки.	Обычно не используется	Не-бизнес-взаимодействия (например, жесты) и прочий код, необходимый для создания полноценного пользовательского опыта на этой странице	Загрузчики данных для фреймворков, ориентированных на SSR (рендеринг на сервере)