Каждый разработчик рано или поздно сталкивается с вопросом: как организовать проект так, чтобы он не превратился в хаос? Или как исправить проект, в котором уже царит хаос?
Начинается всё одинаково: мы делаем простое MVP или проект с ограниченным функционалом, не заморачиваемся по поводу архитектуры и организации кода, ведь проект небольшой и несложный, а сделать его нужно уже здесь и сейчас. Но время идёт, и у бизнеса появляются всё новые требования. Какие‑то изначальные идеи полностью отменяются или меняются до неузнаваемости, разрастается команда, дизайн меняется несколько раз, появляется необходимость покрыть проект тестами, а иногда и необходимость вообще сменить стек технологий. И вот вы уже работаете над кодом, в котором становится всё сложнее вносить изменения в существующий функционал. Всё держится на костылях, становится трудно ориентироваться в куче файлов, и кажется, что всё устроено как‑то не так, как должно быть.
В этот момент мы начинаем задаваться вопросом: «а как нужно писать и организовывать код на самом деле?». В поисках ответа мы читаем статьи, смотрим обучающие видео, доклады и неизбежно натыкаемся на Feature‑Sliced Design (FSD).
Знакомство с FSD
Первое знакомство с FSD выглядит многообещающе. На первый взгляд, это готовая система, способная устранить хаос и привести проект к порядку. Более того, в сообществе FSD нередко называют «лучшей архитектурой для фронтенда», что создаёт определенные ожидания.
Однако на практике всё оказывается не так радужно. Многие из тех кто внедряет FSD на более‑менее крупных проектах, сталкиваются с подобными проблемами:
возникают вопросы о том, какую вложенность виджетов можно считать допустимой
некоторые фичи оказываются настолько «размазаны», что с ними становится сложно работать — чтобы понять или изменить одно флоу, приходится постоянно переключаться между кучей папок и файлов
проблемы с чётким делением сущностей и постоянные разночтения правил
Изучая опыт команд на конференциях и в статьях, можно обнаружить, что многие команды адаптируют FSD на своё усмотрение, отходя от канонического варианта. Часто докладчик начинал свою речь с признания в духе: «Сначала мы неправильно поняли методологию» или «Нам пришлось адаптировать её под себя».
Как оказалось, сами авторы FSD признают эти трудности. Например, в версии 2.1 акцент сместился к «pages‑first», с обоснованием, что предыдущий подход заставлял разработчиков «прыгать по папкам» для изменения одного пользовательского сценария и требовал глубокого понимания бизнес‑контекста, что создавало почву для конфликтов и недопониманий между членами команды. Так что переход к «pages‑first» сделал методологию более интуитивной.
Но возникает закономерный вопрос: если подход требует такой адаптации под каждую команду и каждый проект, то действительно ли он решает одну из основных задач — обеспечение единообразия и предсказуемости?
И здесь мы сталкиваемся с фундаментальной проблемой любой системы: стремление к универсальности неизбежно конфликтует с реальным разнообразием. FSD пытается стандартизировать то, что по своей природе контекстно‑зависимо. И на мой взгляд, сама необходимость в постоянных адаптациях указывает не столько на недостатки, сколько на невозможность создания универсального решения.
Каждая «своя» интерпретация FSD это на самом деле попытка примирить абстрактные правила с конкретными реалиями проекта. Возможно, ценность FSD не в готовых ответах, а в том, что он заставляет команды осознанно подходить к организации кода, даже если конечный результат отличается от некоего канонического, при этом давая скелет, на который можно опереться. И если подходить к этому так, то FSD работает как своеобразный катализатор размышления о нужной конкретно вам системе, а не как жёсткий свод правил.
Тем не менее, остаются вопросы, которые FSD принципиально не решает: как проектировать бизнес‑логику, организовывать управление состоянием, выстраивать взаимодействие с API, обрабатывать ошибки и крайние случаи. А без ответов на эти вопросы любой проект рано или поздно станет трудноподдерживаемым.
Да, FSD частично отвечает на эти вопросы. Как пример, рекомендует отделять бизнес‑логику от UI, помогает разделять части приложения и так далее, однако не даёт конкретных рекомендаций о внутренней реализацией этих частей.
Подмена понятий
Часто в сообществе FSD называют «архитектурой», что создает неправильные ожидания от решения проблем архитектурного характера. И это представление потенциально опасно.
Мы подменяем сложную, абстрактную и невидимую работу по проектированию системы на простую, конкретную и видимую, раскладывая слои по папкам. Эта подмена понятий может привести к тому, что команда считает, что, внедрив FSD, она «занялась архитектурой», и перестает задавать себе по‑настоящему важные архитектурные вопросы. А эти вопросы никуда не исчезают.
На первый взгляд может показаться, что различие между архитектурой и организацией кода и так очевидно и не стоит отдельного обсуждения. Однако вся эта путаница не придумана из головы на пустом месте, а реально существует в нашем сообществе.
Что такое архитектура на самом деле?
Архитектура — это высокоуровневая структура системы, определяющая принципы взаимодействия компонентов и потока данных. Архитектура отвечает на такие вопросы:
Как данные проходят через систему?
Как разделяются ответственности между частями системы?
Какие принципы используются для работы с состоянием и ошибками?
Какие паттерны и принципы используются для изоляции бизнес‑логики от фреймворков и внешних сервисов?
И в то же время существует такое понятие как методология организации кода — это набор правил о том, как структурировать файлы и папки, как их называть, где что размещать, какие правила импортов соблюдать. То есть в отличие от архитектуры, методология организации кода не определяет, как работает приложение в целом, а задаёт правила порядка и структуры.
Поэтому в этом смысле FSD не является архитектурой, хотя и затрагивает некоторые ее аспекты. Это методология организации кода, потому что она предлагает определенную структуру файлов и правила их взаимодействия, но не определяет, как ваше приложение будет работать на высоком уровне.
Из‑за этого также кажутся странными претензии некоторых людей, что «зачем использовать FSD, если есть Clean Architecture», как бы противопоставляя эти понятия, хотя в реальности это разные вещи, решающие разные проблемы. На практике для полноценного проекта нужно сочетать и архитектурные, и организационные, и множество других технических решений.
Даже при соблюдении всех рекомендаций FSD легко получить:
Плохое управление состоянием (например, прямые мутации состояния через UI)
Неоптимизированную работу с API (дублирование запросов в разных фичах и виджетах)
Плохую систему обработки ошибок и крайних случаев (отсутствие централизованной обработки)
Смешение ответственности
Сложности с тестированием
Но это не проблема или недостаток FSD. Проблема возникает, когда от организационной методологии ожидают решения всех технических проблем проекта, что сейчас мы это внедрим и будет «конфетка».
Более того, нет какой‑то одной волшебной архитектуры или библиотеки, которая решит все проблемы, это всегда должна быть комбинация разных подходов для разных задач.
Не существует универсальных решений. Не нужно искать «лучшую архитектуру для фронтенда». Нам нужно научиться задавать правильные вопросы: не «как правильно организовать код?», а «какие проблемы мы пытаемся решить и какие инструменты для этого подходят?». FSD может быть частью ответа, но никогда не будет полным ответом.
Комментарии (17)
13luck
17.06.2025 17:50Ну и ещё что важно, Архитектура опирается на особенности среды, в рамках которой она применяется.
supercat1337
17.06.2025 17:50Хотите бизнес-логику от ui отделить на уровне компонент? Пожалуйста, есть старый добрый Model View Presenter или Model-View-ViewModel .
LyuMih
17.06.2025 17:50Личное мнение
FSD - крайне нерабочая архитектура, в которой сделано 30% нормально, как во всех других архитектурных (наличие папок - да да, они везде есть) и оставшиеся 70% хайп и переусложнения.
В итоге архитектура на FSD превращается в легаси, от которого хочется избавиться и привести проект к более классическому, каноническому виду.
Если в проекте или модуле нужны папки /pages, /components, /api и /utils - то просто создайте их и не делайте мозги себе и команде.
Ценность от FSD крайне преувеличена, а legacy от этого подхода придётся разбирать ещё N лет разработчикам, которые придут после новаторов, которые затащили FSD в проект.
Также она FSD абсолютно сломано без плагинов, которые запрещает импорты компонентов из слоев, которые не должны пересекаться. А без этих плагинов вся головная боль и ответственностьложится на голову разработчиков.
SadOcean
17.06.2025 17:50Статья верно вскрывает слой проблем.
Иронично и то, что просто слоеная архитектура (когда в папочках сложены горами контроллеры, модели, представления и view, точно так же не работоспособны.
Отдельный вопрос, что изоляция и переносимость могут требовать некоторой группировки моделей, а разделение проекта по фичам требует дублировать ту самую слоеную иерархию в каждой фиче. Плюс, зачастую слои не соответствуют полностью, некоторые фичи не требуют визуальной или, наоборот, логической части.
В общем как обычно, волшебной пули нет.
Тем не менее и архитектура, допускающая подобные встройки, и фиче организация очень полезны в тех случаях, когда у вас есть пререквизиты для нее, как то - собственно независимые фичи и стабильная инфраструктура зависимостей для них (например фреймворк). То есть про архитектуру встройки фич кто-то подумал.
В этом случае для команды, особенно начинающих разработчиков, она выглядит действительно как серебрянная пуля - им понятно, куда растить архитектуру, где искать существующий код и, самое главное, куда вставить новый. Шаблонные ответы "вот тут у нас по папке на каждый экран, ищи потроха внутри" очень радуют разработчиков.
cmyser
17.06.2025 17:50в $mol и архитектура и управление состоянием и офлайн first
я бы сказал что он серябряная пуля)
obviouslymilk
17.06.2025 17:50Разве перечисленные болячки не относятся и к классической ("плоской") архитектуре /api /components и т.п.? Заменить в тексте "FSD" на "классическая архитектура", то так и получается.
Хотелось бы услышать о сравнении двух подходов.
sadiolem Автор
17.06.2025 17:50Относятся конечно, но повторюсь, что все это не архитектура
И речь идет именно про FSD, потому что от нее ожидают большего, чем оно есть на самом деле
Vitaly_js
17.06.2025 17:50Начинается всё одинаково: мы делаем простое MVP или проект с ограниченным функционалом, не заморачиваемся по поводу архитектуры и организации кода, ведь проект небольшой и несложный, а сделать его нужно уже здесь и сейчас.
Тут сразу же хочется спросить о чем идет речь? МВП МВП рознь. Бизнес действительно может не видеть разницы между горой говнокода, которая выполняет какие-то функции и готовым продуманным приложением в котором четко выбранны функции для запуска.
Я это все к тому, что не все начинается одинаково. И есть разница между горой говнокода, прототипом и МВП для продакшена.
Часто в сообществе FSD называют «архитектурой», что создает неправильные ожидания от решения проблем архитектурного характера. И это представление потенциально опасно.
Тут хочется сделать замечание по форме. Это не сообщество называло FSD "арзитектурой". Это следует из самого название. Вот эта вот буковка D говорит о том, что тут у нас речь идет о дизайне сиречь проектировании системы. Т.е. из каких кирпичиков состоит система, какие "комнаты" присутствуют в квартире, как это все организуется в квартиру и т.д. и т.п. Таким образом FSD по определению имеет отношение к архитектуре.
Мы подменяем сложную, абстрактную и невидимую работу по проектированию системы на простую, конкретную и видимую, раскладывая слои по папкам. Эта подмена понятий может привести к тому, что команда считает, что, внедрив FSD, она «занялась архитектурой», и перестает задавать себе по‑настоящему важные архитектурные вопросы. А эти вопросы никуда не исчезают.
Я поэтому и не стал комментировать предыдующую главу, потому что этот абзац по сути сконцентрировал в себе всю ее суть.
Тут вы откидываете ряд архитектурных вопросов. И ниже мы поймем почему.
И в то же время существует такое понятие как методология организации кода — это набор правил о том, как структурировать файлы и папки, как их называть, где что размещать, какие правила импортов соблюдать. То есть в отличие от архитектуры, методология организации кода не определяет, как работает приложение в целом, а задаёт правила порядка и структуры.
Поэтому в этом смысле FSD не является архитектурой, хотя и затрагивает некоторые ее аспекты. Это методология организации кода, потому что она предлагает определенную структуру файлов и правила их взаимодействия, но не определяет, как ваше приложение будет работать на высоком уровне.
И вот тут сразу хочется у вас спросить, а что такое приложение? Ну, потому что есть вот дерево с файлами исходных кодов. А есть, бинарник развернутый на сервере. А есть набор бинарников, каждый из которых это отдельное приложение обслуживающееся отдельной коммандой. А пользователь вообще все это видит как единое целое. При этом каждому интересен Только свой взгляд на систему. Например, пользователю вообще наплевать как это все выглядит в исходном коде, или развернуто в сети, или выглядит на схемах для бизнеса.
Я это все к тому, что приложение для различных заинтересованных лиц будет представлено своим представлением. При этом каждое представление должно состоять из ясных элементарных строительных блоков, отношений между строительными блоками, абстракций в которые организуются конкретные строительные блоки и отношения, типом и количеством этих абстракций и т.д. и т.п.
При этом каждое предсталение системы говорит об архитектуре приложения.
Иными словами, вы сузили представление об архитектуре приложения до конкретно некоторых строн системы. Вот и все.
Даже при соблюдении всех рекомендаций FSD легко получить:
А это все потому, что FSD ко всему этому отношения не имеет. Она решает свой ряд архитектурных задач.
sadiolem Автор
17.06.2025 17:50Да, вы правы, с «все начинается одинаково» конечно преувеличение)
Далее я упоминаю, что FSD действительно затрагивает архитектурные вопросы, но лишь частично. И там нет критики FSD за то, что она не решает то, что по определению не собирается решать. Мысль в этом и есть, что не нужно обманываться, будто внедрив FSD все станет круто, у каждого инструмента своя область применения и надо смотреть на архитектуру шире.
Vitaly_js
17.06.2025 17:50Мысль в этом и есть, что не нужно обманываться, будто внедрив FSD все станет круто, у каждого инструмента своя область применения и надо смотреть на архитектуру шире.
Так если надо смотреть на архитектуру шире зачем вы наоборот это видение сужаете?
Например, вы пишете:
Поэтому в этом смысле FSD не является архитектурой, хотя и затрагивает некоторые ее аспекты. Это методология организации кода, потому что она предлагает определенную структуру файлов и правила их взаимодействия, но не определяет, как ваше приложение будет работать на высоком уровне.
Тут сама по себе фигура речи странная: "FSD не является архитектурой". Так еще и архитектурные задачи связанные с организацией кода рассматриваете как будто сами по себе. Хотя представление приложения в виде файлового дерева имеет прямое отношение к архитектур.
Далее:
Архитектура — это высокоуровневая структура системы, определяющая принципы взаимодействия компонентов и потока данных. Архитектура отвечает на такие вопросы:
....
И еще больше сужаете представление об архитектуре.
Но если действительно смотреть шире, то нужно рассматривать приложение со всех проблемных сторон.
А вы, получается, на свои собственные грабли наступили. Как будто если думать только о том, что вы называете "высокоуровневой структурой системы" на этом все архитектурные моменты заканчиваются.
sadiolem Автор
17.06.2025 17:50Тут я полностью согласен, что представление об архитектуре шире и имеет кучу аспектов.
А это определение скорее является упрощением для подчеркивания контраста между разными уровнями, где FSD это потенциальное решение лишь определенной части вопросов и проблем. То есть отношение к архитектуре в конечном итоге оно конечно имеет и это упоминается несколько раз, просто говорится о том, что в итоге это все же не архитектура в полном смысле.
В конце концов, полный академический разбор всех этих аспектов заслуживает отдельной статьи, здесь не совсем про это. Но возможно было бы уместно это упомянуть.
markelov69
17.06.2025 17:50Почему Feature-Sliced Design (FSD) не спасет ваш проект
Потому что его предназначение - уничтожить ваш проект. И довести ущербность структуры файлов и папок до максимума убогости. Всё для того, что вы и все остальные кто будет работать с этим "чудо" проектом страдали.
azat_sync
В относительно небольших проектах 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-майндсет.
korvint
Интересуюсь этим вопросом. Не могли бы Вы привести реальный пример организации папок features и widgets? Никак не могу уловить разницу. А лучше один раз увидеть как говорится.
LyuMih
FSD и не нужно. Любая структура будет достаточна для небольших проектов, т.к. там нужно решать проблемы небольших проектов.
А на средних и больших появляются проблемы, дополнительно связанные с FSD.