Comments 19
В относительно небольших проектах FSD отлично работает:
app — инициализация приложения, роутеров, стейт-менеджеров, i18n-библиотек
pages — собственно, страницы, могут иметь локальные хранилища для хранения состояния
widgets — всё, что рендерится в прямоугольник и отображается на экране; локальные хранилища для хранения состояния конкретного виджета
features — всё, что не рендерится в самостоятельный прямоугольник (к примеру, рендеринг геометрий на карте; набор компонентов из одной доменной области, используемые в разных виджетах) и всё, что работает с более чем одной сущностью — самый разнообразный слой, кмк
entities — запросы к API, адаптеры типа tanstack/*-query, мапперы полей, подключение mock-данных, контроллеры WebSocket-соединений, работа sync engine; компоненты, отображающие состояние строго одной сущности, i18n-словари терминов сущности, типы, enum-ы
shared — экземпляры глобальных штуковин типа HTTP-клиента, query-клиента, стейт-менеджера; функции-хелперы, кастомные компоненты поверх UI-кита
На типичных задачах выбор только между widgets и features, и если выбор не очевиден, я начинаю с features.
Если изменилась бизнес-логика, связанная с сущностями — вы это поймёте и без подсказок, аналогично с глобальными штуками в app и shared. Какие-то из pages можно значительно параметризовать из app, и это тоже нормально.
Если прям очень необходим ещё один слой — его вполне можно завести, в этом тоже ничего страшного нет, только исчерпывающе опишите в документации. В моих проектах есть «патчи» поверх внешних соглашений; пример: Conventional Commits, но сообщение коммита должно быть на русском и отвечать на вопрос «что сделано». Это расписано в документации, и вопросов у коллег, в том числе новых, ноль. Или ESLint-конфиг от Airbnb, но с конкретно описанными изменениями.
И да, разумеется, FSD это только для UI-приложений. И да, его надо уметь готовить, однако это несложно. На мой взгляд, это система папок, плюс SOLID, насколько возможно, плюс слегка DDD-майндсет.
Интересуюсь этим вопросом. Не могли бы Вы привести реальный пример организации папок features и widgets? Никак не могу уловить разницу. А лучше один раз увидеть как говорится.
В относительно небольших проектах
FSD и не нужно. Любая структура будет достаточна для небольших проектов, т.к. там нужно решать проблемы небольших проектов.
А на средних и больших появляются проблемы, дополнительно связанные с FSD.
Ну и ещё что важно, Архитектура опирается на особенности среды, в рамках которой она применяется.
Хотите бизнес-логику от ui отделить на уровне компонент? Пожалуйста, есть старый добрый Model View Presenter или Model-View-ViewModel .
Личное мнение
FSD - крайне нерабочая архитектура, в которой сделано 30% нормально, как во всех других архитектурных (наличие папок - да да, они везде есть) и оставшиеся 70% хайп и переусложнения.
В итоге архитектура на FSD превращается в легаси, от которого хочется избавиться и привести проект к более классическому, каноническому виду.
Если в проекте или модуле нужны папки /pages, /components, /api и /utils - то просто создайте их и не делайте мозги себе и команде.
Ценность от FSD крайне преувеличена, а legacy от этого подхода придётся разбирать ещё N лет разработчикам, которые придут после новаторов, которые затащили FSD в проект.
Также она FSD абсолютно сломано без плагинов, которые запрещает импорты компонентов из слоев, которые не должны пересекаться. А без этих плагинов вся головная боль и ответственностьложится на голову разработчиков.
Статья верно вскрывает слой проблем.
Иронично и то, что просто слоеная архитектура (когда в папочках сложены горами контроллеры, модели, представления и view, точно так же не работоспособны.
Отдельный вопрос, что изоляция и переносимость могут требовать некоторой группировки моделей, а разделение проекта по фичам требует дублировать ту самую слоеную иерархию в каждой фиче. Плюс, зачастую слои не соответствуют полностью, некоторые фичи не требуют визуальной или, наоборот, логической части.
В общем как обычно, волшебной пули нет.
Тем не менее и архитектура, допускающая подобные встройки, и фиче организация очень полезны в тех случаях, когда у вас есть пререквизиты для нее, как то - собственно независимые фичи и стабильная инфраструктура зависимостей для них (например фреймворк). То есть про архитектуру встройки фич кто-то подумал.
В этом случае для команды, особенно начинающих разработчиков, она выглядит действительно как серебрянная пуля - им понятно, куда растить архитектуру, где искать существующий код и, самое главное, куда вставить новый. Шаблонные ответы "вот тут у нас по папке на каждый экран, ищи потроха внутри" очень радуют разработчиков.
Разве перечисленные болячки не относятся и к классической ("плоской") архитектуре /api /components и т.п.? Заменить в тексте "FSD" на "классическая архитектура", то так и получается.
Хотелось бы услышать о сравнении двух подходов.
Начинается всё одинаково: мы делаем простое MVP или проект с ограниченным функционалом, не заморачиваемся по поводу архитектуры и организации кода, ведь проект небольшой и несложный, а сделать его нужно уже здесь и сейчас.
Тут сразу же хочется спросить о чем идет речь? МВП МВП рознь. Бизнес действительно может не видеть разницы между горой говнокода, которая выполняет какие-то функции и готовым продуманным приложением в котором четко выбранны функции для запуска.
Я это все к тому, что не все начинается одинаково. И есть разница между горой говнокода, прототипом и МВП для продакшена.
Часто в сообществе FSD называют «архитектурой», что создает неправильные ожидания от решения проблем архитектурного характера. И это представление потенциально опасно.
Тут хочется сделать замечание по форме. Это не сообщество называло FSD "арзитектурой". Это следует из самого название. Вот эта вот буковка D говорит о том, что тут у нас речь идет о дизайне сиречь проектировании системы. Т.е. из каких кирпичиков состоит система, какие "комнаты" присутствуют в квартире, как это все организуется в квартиру и т.д. и т.п. Таким образом FSD по определению имеет отношение к архитектуре.
Мы подменяем сложную, абстрактную и невидимую работу по проектированию системы на простую, конкретную и видимую, раскладывая слои по папкам. Эта подмена понятий может привести к тому, что команда считает, что, внедрив FSD, она «занялась архитектурой», и перестает задавать себе по‑настоящему важные архитектурные вопросы. А эти вопросы никуда не исчезают.
Я поэтому и не стал комментировать предыдующую главу, потому что этот абзац по сути сконцентрировал в себе всю ее суть.
Тут вы откидываете ряд архитектурных вопросов. И ниже мы поймем почему.
И в то же время существует такое понятие как методология организации кода — это набор правил о том, как структурировать файлы и папки, как их называть, где что размещать, какие правила импортов соблюдать. То есть в отличие от архитектуры, методология организации кода не определяет, как работает приложение в целом, а задаёт правила порядка и структуры.
Поэтому в этом смысле FSD не является архитектурой, хотя и затрагивает некоторые ее аспекты. Это методология организации кода, потому что она предлагает определенную структуру файлов и правила их взаимодействия, но не определяет, как ваше приложение будет работать на высоком уровне.
И вот тут сразу хочется у вас спросить, а что такое приложение? Ну, потому что есть вот дерево с файлами исходных кодов. А есть, бинарник развернутый на сервере. А есть набор бинарников, каждый из которых это отдельное приложение обслуживающееся отдельной коммандой. А пользователь вообще все это видит как единое целое. При этом каждому интересен Только свой взгляд на систему. Например, пользователю вообще наплевать как это все выглядит в исходном коде, или развернуто в сети, или выглядит на схемах для бизнеса.
Я это все к тому, что приложение для различных заинтересованных лиц будет представлено своим представлением. При этом каждое представление должно состоять из ясных элементарных строительных блоков, отношений между строительными блоками, абстракций в которые организуются конкретные строительные блоки и отношения, типом и количеством этих абстракций и т.д. и т.п.
При этом каждое предсталение системы говорит об архитектуре приложения.
Иными словами, вы сузили представление об архитектуре приложения до конкретно некоторых строн системы. Вот и все.
Даже при соблюдении всех рекомендаций FSD легко получить:
А это все потому, что FSD ко всему этому отношения не имеет. Она решает свой ряд архитектурных задач.
Да, вы правы, с «все начинается одинаково» конечно преувеличение)
Далее я упоминаю, что FSD действительно затрагивает архитектурные вопросы, но лишь частично. И там нет критики FSD за то, что она не решает то, что по определению не собирается решать. Мысль в этом и есть, что не нужно обманываться, будто внедрив FSD все станет круто, у каждого инструмента своя область применения и надо смотреть на архитектуру шире.
Мысль в этом и есть, что не нужно обманываться, будто внедрив FSD все станет круто, у каждого инструмента своя область применения и надо смотреть на архитектуру шире.
Так если надо смотреть на архитектуру шире зачем вы наоборот это видение сужаете?
Например, вы пишете:
Поэтому в этом смысле FSD не является архитектурой, хотя и затрагивает некоторые ее аспекты. Это методология организации кода, потому что она предлагает определенную структуру файлов и правила их взаимодействия, но не определяет, как ваше приложение будет работать на высоком уровне.
Тут сама по себе фигура речи странная: "FSD не является архитектурой". Так еще и архитектурные задачи связанные с организацией кода рассматриваете как будто сами по себе. Хотя представление приложения в виде файлового дерева имеет прямое отношение к архитектур.
Далее:
Архитектура — это высокоуровневая структура системы, определяющая принципы взаимодействия компонентов и потока данных. Архитектура отвечает на такие вопросы:
....
И еще больше сужаете представление об архитектуре.
Но если действительно смотреть шире, то нужно рассматривать приложение со всех проблемных сторон.
А вы, получается, на свои собственные грабли наступили. Как будто если думать только о том, что вы называете "высокоуровневой структурой системы" на этом все архитектурные моменты заканчиваются.
Тут я полностью согласен, что представление об архитектуре шире и имеет кучу аспектов.
А это определение скорее является упрощением для подчеркивания контраста между разными уровнями, где FSD это потенциальное решение лишь определенной части вопросов и проблем. То есть отношение к архитектуре в конечном итоге оно конечно имеет и это упоминается несколько раз, просто говорится о том, что в итоге это все же не архитектура в полном смысле.
В конце концов, полный академический разбор всех этих аспектов заслуживает отдельной статьи, здесь не совсем про это. Но возможно было бы уместно это упомянуть.
Почему Feature-Sliced Design (FSD) не спасет ваш проект
Потому что его предназначение - уничтожить ваш проект. И довести ущербность структуры файлов и папок до максимума убогости. Всё для того, что вы и все остальные кто будет работать с этим "чудо" проектом страдали.
По личному опыту, реализовав три проекта (логистикп) с соблюдением FSD могу сказать, что она очень помогла нам разделить бизнес логику с огромным количеством сущностей и бизнес-процессов. Уменьшилось количество регрессий, так как каждый слайс в своем слое не пересекается с другим в своем слое.
Из минусов - сложно вкатиться новым разработчикам, не имеющим опыта с FSD.
Если ваш проект не ecom, то примеры из документации переложить на ваш проект - непростая задача.
При использовании маршрутизации nuxtjs - FSD выходит из чата (спасибо pages)
Почему Feature-Sliced Design (FSD) не спасет ваш проект