Мой опыт работ c архитектурой FSD

В этой статье я хочу поделиться своим опытом разработки приложений с применением подхода FSD (Feature-Sliced Design). Здесь не будут рассматривать ее детально, так как на этот счет есть достаточно хороших материалов, начиная с официального сайта (изображения в этой записи взяты именно с него), и заканчивая статьями на Хабре.

Лично мне этот подход показался очень удобным. Причем не только применительно к новым проектам, которые изначально можно структурировать нужным образом. Но также и применительно к проектам, которые кто-то до меня уже вел и оставил в весьма запутанном состоянии. Следуя простым правилам, шаг за шагом, можно привести в порядок и сделать удобным для развития любую кодовую базу. Именно об этих простых правилах и будет данная статья. В свое время я их не нашел и выработал уже на собственном опыте. Надеюсь, мой опыт окажется полезным для кого-нибудь еще.

Весь код разбивается на слои:

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

Здесь важна иерархия. Элементы могут импортировать и использовать внутри себя только элементы, находящиеся в слое более низкого уровня. Так элемент, находящийся в слое features может использовать элементы из слоев entities и shared, но из своего же слоя или более высоких слоев он ничего применять уже не может. Благодаря этому правилу проект приобретает понятную и четкую структуру.

Например, внося правки в виджет "Корзина" мы можем не опасаться, что они как-то затронут виджет "Список товаров" или изменят логику фичи (feature) ответственной за расчет размера скидки. Изменения коснутся только самого виджета и страниц, на которых он располагается. Соответственно, чем на более низкий уровень мы опускаемся, тем более глобальными и опасными становятся правки.

Итак, опишу подход, который помогает мне придавать проектам удобную для работы структуру.

Настройка подключения к базе данных, аутентификации, служб для отправки SMS и т.п. Для этих целей у меня создана отдельная папка "shared/services".

Также можно сразу прописать основные типы, связанные с работой REST API и т.п.

Теперь, когда все сторонние сервисы, с которыми будет взаимодействовать наше приложение, аккуратно собраны в одном месте, можно приступать ко второму шагу.

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

Например, бизнес-сущность NFT (в моем примере использовалась Prisma)

Эти два слоя содержат в себе уже бизнес-логику. Я объединил эти два слоя в один шаг, так как граница между ними не всегда очевидна. Формально, разграничение должно быть следующим:

Feature: какое-то ценное действие вроде регистрации пользователя или формы редактирования товара.

Widget: выводит компоненты, создавая из них единый изолированный блок, который уже можно размещать на страницах.

На практике здесь много пограничных ситуаций. Поэтому я рекомендую по умолчанию любой элемент рассматривать как Widget и размещать весь связанный с ним код в его папке. Если какая-то часть виджета окажется восстребованной в другом виджете, то она выводиться в отдельную feature - опускается на слой ниже, чтобы стать доступной для всех widgets.

Порядок действий выходит следующий:

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

По сути - самый верхний уровень. Страницы должны быть максимально "тонкими" и отвечать только за загрузку связанных с ними данных(загрузка с сервера информации о товаре, на основе productSlug в url страницы, например), а также порядок размещения виджетов.

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

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

Код, составленный таким образом, довольно легко поддерживать. Вы сразу можете определить "опасные" и "безопасные" для правки части, а также понять, на что именно повлияют изменения. Изменяя форму для ввода данных банковской карты, расположенную в слое features, вы можете совершенно не переживать за непредвиденные эффекты в других features и, тем более, коде, расположенным в более низких слоях. Достаточно лишь будет проверить те несколько виджетов, где форма используется. Если утилита размещена в папке какого-то виджета, это значит, что она используется только для этого виджета и нигде более.

Сравните, насколько это удобнее, чем иметь дело с переполненными папками components и lib.

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

#fsd #featuresliceddesign