Введение Фронтенд-разработчики часто сталкиваются с проблемой, связанной с архитектурой приложения. Это требует использования архитектуры, которая может легко масштабироваться и обеспечивать слабую связь и высокую связанность между модулями приложения. В этой статье рассматривается архитектура 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: Официальная документация Пример. Клиент GitHub Пример. Магазин кроссовок и обуви Nike Пример. Судоку Этот пост может быть длинным, но я надеюсь, что вы узнали что-то новое. Я ценю, что вы дочитали этот пост. Если у вас есть какие-либо мысли или вопросы, не стесняйтесь оставлять комментарии! Также опубликовано здесь
