Введение
Фронтенд-разработчики часто сталкиваются с проблемой, связанной с архитектурой приложения. Это требует использования архитектуры, которая может легко масштабироваться и обеспечивать слабую связь и высокую связанность между модулями приложения.
В этой статье рассматривается архитектура Feature-Sliced Design, поскольку, на мой взгляд, она является лучшей среди доступных вариантов. В нем также исследуется идея FSD и проблемы, которые решает эта архитектурная методология.
Мы сравним FSD с классической и модульной архитектурой и рассмотрим их плюсы и минусы.
Прежде всего, давайте различать три понятия: слой, срез и сегмент.
Слои
Уровни — это каталоги верхнего уровня и первый уровень декомпозиции приложения. Их количество ограничено — максимум 7 слоев — и стандартизировано, хотя некоторые из них являются необязательными.
В настоящее время выделяют следующие слои:
Каждый уровень имеет свою зону ответственности и ориентирован на бизнес. Рассмотрим каждый слой отдельно.
- app: здесь инициализируется логика приложения. Здесь определяются провайдеры, маршрутизаторы, глобальные стили, объявления глобальных типов и т. д. Он служит точкой входа для приложения.
- процессы: этот уровень обрабатывает процессы, охватывающие несколько страниц, такие как многоэтапная регистрация. Этот слой считается устаревшим, но время от времени все еще может встречаться. Это необязательный слой.
- страницы: этот уровень включает страницы приложения.
- виджеты: это автономные компоненты пользовательского интерфейса, используемые на страницах.
- функции: этот уровень имеет дело с пользовательскими сценариями и функциями, имеющими ценность для бизнеса. Например, лайки, написание обзоров, рейтинг товаров и т. д. Это необязательный слой.
- объекты: этот уровень представляет бизнес-объекты. Эти объекты могут включать пользователей, обзоры, комментарии и т. д. Это необязательный уровень.
- общий: этот уровень содержит повторно используемые компоненты и утилиты, которые не привязаны к конкретной бизнес-логике. Он включает в себя UI-кит, конфигурацию Axios, конфигурацию приложения, помощники, не привязанные к бизнес-логике и т. д.
Эти уровни помогают организовать базу кода и создать модульную, поддерживаемую и масштабируемую архитектуру.
Одной из ключевых особенностей Feature-Sliced Design является его иерархическая структура. В этой структуре сущности не могут использовать функциональные возможности функций, поскольку функции находятся выше в иерархии.
Аналогично, функции не могут использовать компоненты виджетов или процессов, поскольку слои выше могут использовать только слои ниже. Это сделано для поддержания линейного потока, направленного только в одном направлении. Чем ниже уровень расположен в иерархии, тем рискованнее вносить в него изменения, поскольку, скорее всего, он будет использоваться в большем количестве мест кода. Например, набор пользовательского интерфейса на общем слое используется в функциях, виджетах и даже слоях страниц.
Ломтики
В каждом из слоев есть подкаталоги — слайсы — второй уровень декомпозиции приложения. В срезах связь осуществляется не с абстрактными вещами, а с конкретными бизнес-сущностями. Основная цель срезов — группировать код по его значению.
Имена срезов не стандартизированы, так как напрямую определяются бизнес-направлением проекта. Например, в фотогалерее могут быть такие разделы, как фото, альбом и галерея. Социальная сеть потребует таких фрагментов, как сообщения, пользователи и ленты новостей.
Близко связанные фрагменты могут быть структурно сгруппированы в каталоге, но они должны соответствовать тем же правилам изоляции, что и другие фрагменты — не должно быть общего доступа к коду в этом каталоге.
Сегменты
Каждый срез состоит из сегментов. Сегменты помогают разделить код внутри фрагмента в зависимости от его назначения. В зависимости от договоренностей команды сегменты могут меняться по составу и названию. Чаще всего используются следующие сегменты:
- api — необходимые запросы к серверу.
- UI — компоненты пользовательского интерфейса среза.
- модель - Бизнес-логика, т.е. взаимодействие с государством. Например, действия и селекторы.
- lib — вспомогательная функциональность, используемая внутри слайса.
- config — необходимая конфигурация слайса, но сегмент config встречается редко.
- consts — необходимые константы.
Публичный API
Каждый срез и сегмент имеет общедоступный API. Public API представлен файлом index.js или index.ts, который позволяет извлечь из среза или сегмента наружу только необходимую функциональность и изолировать ненужную функциональность. Индексный файл служит точкой входа.
Правила для публичного API:
- Фрагменты и сегменты приложения используют только те функции и компоненты фрагмента, которые определены в индексном файле общедоступного API.
- Внутренняя часть среза или сегмента, которая не определена в Public API, считается изолированной и открытой для доступа только внутри самого среза или сегмента.
Public API упрощает работу с импортом и экспортом, поэтому при внесении изменений в приложение нет необходимости менять импорты везде в коде.
Глубже в архитектуру
Абстракция и бизнес-логика
Чем выше уровень, тем больше он привязан к конкретному бизнес-узлу и тем больше бизнес-логики он содержит. Чем ниже уровень, тем больше на нем абстракций, возможности повторного использования и отсутствия автономности.
Как ФСД решает проблему?
Одна из задач Feature-Sliced Design — добиться слабой связи и высокой связности. Важно понять, как FSD достигает такого результата.
В ООП эти проблемы уже давно решаются с помощью таких концепций, как полиморфизм , инкапсуляция , наследование и абстракция . Эти концепции обеспечивают изоляцию, возможность повторного использования и универсальность кода, при этом в зависимости от того, как используется компонент или функциональность, получаются разные результаты.
Функциональный дизайн помогает применить эти принципы во внешнем интерфейсе.
Абстракция и полиморфизм достигаются за счет слоев. Поскольку нижние уровни являются абстрактными, их можно повторно использовать в более высоких слоях, и в зависимости от условий компонент или функциональность могут работать по-разному в зависимости от заданных параметров или реквизитов.
Инкапсуляция достигается посредством Public API, который изолирует ненужное извне в срезах и сегментах. Доступ к внутренним сегментам среза ограничен, а общедоступный API — единственный способ получить доступ к функциям и компонентам среза или сегмента.
Наследование также достигается посредством слоев, поскольку более высокие уровни могут повторно использовать нижние уровни.
Сравнение с классической архитектурой
Я думаю, вы много раз сталкивались с классической архитектурой. Большинство авторов используют его в образовательных статьях и видеороликах на YouTube из-за его простоты. Для классической архитектуры не существует определенного стандарта. Однако часто можно увидеть следующий формат:
Классическая архитектура имеет заметные недостатки. Самый большой из них заключается в том, что проект становится сложно поддерживать из-за неявных связей между компонентами и беспорядка в модулях. Недостатки классической архитектуры со временем становятся все более очевидными. Чем дольше развивается проект, тем больше архитектура приложения превращается в запутанную путаницу, которую трудно распутать.
Классическая архитектура подходит для небольших проектов без текущего обслуживания или домашних проектов.
Функциональный дизайн благодаря своим концепциям и стандартам предотвращает проблемы классической архитектуры.
Однако уровень понимания и навыков разработчиков, работающих с FSD, должен быть выше, чем при работе с классической архитектурой. Обычно разработчики с опытом менее 2 лет о FSD не слышали.
Однако при работе с Feature-Sliced Design проблемы необходимо решать «сейчас», а не «позже». Проблемы в коде и отклонения от концепций становятся очевидными сразу.
Сравнение с простой модульной архитектурой
Простая модульная архитектура имеет ряд недостатков:
- Иногда неясно, куда поместить функциональность в модули или компоненты.
- Трудности в использовании модулей внутри другого модуля.
- Проблемы с хранением хозяйствующих субъектов.
- Неявные зависимости в глобальных функциях, приводящие к запутанной структуре.
Кажется, что в любых сложных или умеренно сложных проектах Feature-Sliced Design следует отдавать предпочтение простой модульной архитектуре. FSD решает множество фундаментальных архитектурных проблем и имеет мало недостатков.
С точки зрения простоты и скорости разработки простая модульная архитектура может иметь преимущество перед FSD. Если необходим MVP или разрабатывается недолговечный проект, простая модульная архитектура может оказаться более подходящей, чем FSD. Но в любом другом случае функциональный дизайн выглядит предпочтительнее.
Потенциал функционального дизайна
FSD — молодая архитектурная методология. Однако его уже используют многие банковские, финтех-, B2B-компании, компании электронной коммерции и другие. Вот ссылка на выпуск GitHub со списком компаний: GitHub Issue .
Репозиторий GitHub с официальной документацией FSD на момент публикации этой статьи имел более 1,1 тыс. звезд. Документация активно расширяется, а команда разработчиков и сообщество FSD в Telegram и Discord доступны круглосуточно и без выходных, чтобы помочь людям с вопросами, связанными с архитектурой.
Потенциал этой архитектуры высоко ценится, и ее использование широко распространено среди крупных компаний по всему миру. При правильном внедрении FSD может стать доминирующим архитектурным решением в области внешней разработки.
Преимущества и недостатки архитектуры
Преимущества
- Компоненты архитектуры можно легко заменить, добавить или удалить.
- Стандартизация архитектуры
- Масштабируемость
- Методология не зависит от стека разработки.
- Контролируемые и явные соединения между модулями без неожиданных побочных эффектов.
- Бизнес-ориентированная архитектурная методология.
Недостатки
- Более высокий входной барьер по сравнению со многими другими архитектурными решениями.
- Требует осведомленности, командной культуры и приверженности концепциям.
- Проблемы и проблемы необходимо решать немедленно, а не позже. Проблемы с кодом и отклонения от концепций видны сразу. Однако это можно рассматривать и как преимущество.
Заключение
Feature-Sliced Design — интересное и ценное открытие, которое фронтенд-разработчики должны знать и уметь использовать. FSD может предоставить командам гибкую, стандартизированную и масштабируемую архитектуру и культуру разработки. Однако использование положительных сторон методологии требует знаний, осведомленности и дисциплины внутри команды.
FSD выделяется среди других архитектур благодаря четкой бизнес-ориентации, определению сущностей, функциональному составу и составу компонентов приложения.
Вы также можете самостоятельно изучить примеры использования FSD в проектах и официальную документацию Feature-Sliced Design:
Пример. Магазин кроссовок и обуви Nike
Этот пост может быть длинным, но я надеюсь, что вы узнали что-то новое. Я ценю, что вы дочитали этот пост.
Если у вас есть какие-либо мысли или вопросы, не стесняйтесь оставлять комментарии!
Также опубликовано здесь
