paint-brush
Лучшая сложная архитектура внешнего интерфейса: что нужно знать о функциональном дизайнек@mmmidas
2,536 чтения
2,536 чтения

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

к Yan Levin
Yan Levin HackerNoon profile picture

Yan Levin

@mmmidas

22 y.o. front-end developer with a special love for learning...

8 мин read2024/01/18
Read on Terminal Reader
Read this story in a terminal
Print this story
Read this story w/o Javascript
Read this story w/o Javascript

Слишком долго; Читать

В этой статье рассматривается архитектура Feature-Sliced Design, поскольку, на мой взгляд, она является лучшей среди доступных вариантов. В нем также исследуется идея FSD и проблемы, которые решает эта архитектурная методология.
featured image - Лучшая сложная архитектура внешнего интерфейса: что нужно знать о функциональном дизайне
Yan Levin HackerNoon profile picture
Yan Levin

Yan Levin

@mmmidas

22 y.o. front-end developer with a special love for learning and creating

0-item
1-item
2-item

STORY’S CREDIBILITY

Original Reporting

Original Reporting

This story contains new, firsthand information uncovered by the writer.

DYOR

DYOR

The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch before making any investment decisions or decisions regarding your health or security. (Do not regard any of this content as professional investment advice, or health advice)

Review

Review

This story will praise and/or roast a product, company, service, game, or anything else people like to review on the Internet.

Введение

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


В этой статье рассматривается архитектура Feature-Sliced Design, поскольку, на мой взгляд, она является лучшей среди доступных вариантов. В нем также исследуется идея FSD и проблемы, которые решает эта архитектурная методология.


Мы сравним FSD с классической и модульной архитектурой и рассмотрим их плюсы и минусы.


Прежде всего, давайте различать три понятия: слой, срез и сегмент.

Слои, фрагменты, сегменты

Слои, фрагменты, сегменты

Слои

Уровни — это каталоги верхнего уровня и первый уровень декомпозиции приложения. Их количество ограничено — максимум 7 слоев — и стандартизировано, хотя некоторые из них являются необязательными.


В настоящее время выделяют следующие слои:

Слои

Слои

Каждый уровень имеет свою зону ответственности и ориентирован на бизнес. Рассмотрим каждый слой отдельно.


  • app: здесь инициализируется логика приложения. Здесь определяются провайдеры, маршрутизаторы, глобальные стили, объявления глобальных типов и т. д. Он служит точкой входа для приложения.


  • процессы: этот уровень обрабатывает процессы, охватывающие несколько страниц, такие как многоэтапная регистрация. Этот слой считается устаревшим, но время от времени все еще может встречаться. Это необязательный слой.


  • страницы: этот уровень включает страницы приложения.


  • виджеты: это автономные компоненты пользовательского интерфейса, используемые на страницах.


  • функции: этот уровень имеет дело с пользовательскими сценариями и функциями, имеющими ценность для бизнеса. Например, лайки, написание обзоров, рейтинг товаров и т. д. Это необязательный слой.


  • объекты: этот уровень представляет бизнес-объекты. Эти объекты могут включать пользователей, обзоры, комментарии и т. д. Это необязательный уровень.


  • общий: этот уровень содержит повторно используемые компоненты и утилиты, которые не привязаны к конкретной бизнес-логике. Он включает в себя UI-кит, конфигурацию Axios, конфигурацию приложения, помощники, не привязанные к бизнес-логике и т. д.


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

Слои Github

Слои Github

Одной из ключевых особенностей Feature-Sliced Design является его иерархическая структура. В этой структуре сущности не могут использовать функциональные возможности функций, поскольку функции находятся выше в иерархии.


Аналогично, функции не могут использовать компоненты виджетов или процессов, поскольку слои выше могут использовать только слои ниже. Это сделано для поддержания линейного потока, направленного только в одном направлении.

Структура слоев

Структура слоев

Чем ниже уровень расположен в иерархии, тем рискованнее вносить в него изменения, поскольку, скорее всего, он будет использоваться в большем количестве мест кода. Например, набор пользовательского интерфейса на общем слое используется в функциях, виджетах и даже слоях страниц.

Ломтики

В каждом из слоев есть подкаталоги — слайсы — второй уровень декомпозиции приложения. В срезах связь осуществляется не с абстрактными вещами, а с конкретными бизнес-сущностями. Основная цель срезов — группировать код по его значению.


Имена срезов не стандартизированы, так как напрямую определяются бизнес-направлением проекта. Например, в фотогалерее могут быть такие разделы, как фото, альбом и галерея. Социальная сеть потребует таких фрагментов, как сообщения, пользователи и ленты новостей.


Близко связанные фрагменты могут быть структурно сгруппированы в каталоге, но они должны соответствовать тем же правилам изоляции, что и другие фрагменты — не должно быть общего доступа к коду в этом каталоге.

Ломтики

Ломтики

Сегменты

Каждый срез состоит из сегментов. Сегменты помогают разделить код внутри фрагмента в зависимости от его назначения. В зависимости от договоренностей команды сегменты могут меняться по составу и названию. Чаще всего используются следующие сегменты:


  • api — необходимые запросы к серверу.


  • UI — компоненты пользовательского интерфейса среза.


  • модель - Бизнес-логика, т.е. взаимодействие с государством. Например, действия и селекторы.
  • lib — вспомогательная функциональность, используемая внутри слайса.


  • config — необходимая конфигурация слайса, но сегмент config встречается редко.


  • consts — необходимые константы.

Публичный API

Каждый срез и сегмент имеет общедоступный API. Public API представлен файлом index.js или index.ts, который позволяет извлечь из среза или сегмента наружу только необходимую функциональность и изолировать ненужную функциональность. Индексный файл служит точкой входа.


Правила для публичного API:


  • Фрагменты и сегменты приложения используют только те функции и компоненты фрагмента, которые определены в индексном файле общедоступного API.


  • Внутренняя часть среза или сегмента, которая не определена в Public API, считается изолированной и открытой для доступа только внутри самого среза или сегмента.


Public API упрощает работу с импортом и экспортом, поэтому при внесении изменений в приложение нет необходимости менять импорты везде в коде.

Публичный API

Публичный 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

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


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


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


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

L O A D I N G
. . . comments & more!

About Author

Yan Levin HackerNoon profile picture
Yan Levin@mmmidas
22 y.o. front-end developer with a special love for learning and creating

БИРКИ

ЭТА СТАТЬЯ БЫЛА ПРЕДСТАВЛЕНА В...

Permanent on Arweave
Read on Terminal Reader
Read this story in a terminal
 Terminal
Read this story w/o Javascript
Read this story w/o Javascript
 Lite
X REMOVE AD