Лучшая сложная архитектура внешнего интерфейса: что нужно знать о функциональном дизайне

Введение

Фронтенд-разработчики часто сталкиваются с проблемой, связанной с архитектурой приложения. Это требует использования архитектуры, которая может легко масштабироваться и обеспечивать слабую связь и высокую связанность между модулями приложения.

В этой статье рассматривается архитектура 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

Пример. Судоку

Этот пост может быть длинным, но я надеюсь, что вы узнали что-то новое. Я ценю, что вы дочитали этот пост.

Если у вас есть какие-либо мысли или вопросы, не стесняйтесь оставлять комментарии!

Также опубликовано здесь