WIP: Текущая версия методологии находится на стадии разработки и некоторые детали могут измениться

Методология для проектирования frontend проектов, нацеленная на разделение приложения согласно бизнес-логике и областям ответственности.

• Обеспечивает понятность, контролируемость и адаптивность архитектуры
• Основана на проверенных временем практиках проектирования и концепциях

  SOLID, GRASP, DDD, Separation of Concerns, Vertical Slices, Public API, Isolation

• Предлагает разделять проект согласно бизнес-юнитам

Примечание: Методология не привязана к конкретному стеку и применима к любым фронтенд-проектам в целом.

Но текущая версия приводит примеры и проработана на базе связки JavaScript + React

Обычно, подходы построения архитектуры фронтенда от проекта к проекту переизобретаются с нуля, пополняя тем самым "проектные знания"

Несмотря на то, что специфика фронтенд-проектов отличается не так значительно

При этом, неверно принятые решения зачастую приводят к проблемам масштабируемости проекта и команды.

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

Да, практик и паттернов много (SOLID, GRASP, DDD, ...)

Но для фронтенда крайне трудно найти устоявшиеся и конкретные подходы

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

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

Примечание: Модуль - структурная единица проекта (файл / директория)

Модули распределяются согласно скоупу влияния, бизнес-ответственности и техническому назначению

Благодаря этому архитектура стандартизируется и становится более простой для ознакомления

Каждый компонент архитектуры имеет свое назначение и не влияет на другие

Благодаря этому под новые требования можно независимо модифицировать функциональность приложения без непредвиденных последствий

Каждый модуль является независимым и самодостаточным

Благодаря этому можно переписать его с нуля без неожиданных сайд-эффектов

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

Благодаря этому легко добавлять и онбордить новых людей в команду, а также расширять функциональность проекта

Каждый модуль имеет свои ограничения и рекоммендации на переиспользуемость согласно своему слою

Благодаря этому сохраняется баланс между соблюдением принципа DRY и возможности кастомизировать логику модуля без оверхедных переопределений

Каждый модуль должен иметь на верхнем уровне декларацию своего публичного API

• Для подключения в другие модули, без нужды обращаться к внутренней структуре данного модуля
• Для изоляции деталей реализации от модулей-потребителей
• Также Public API должен защищать интерфейс модуля после рефакторинга - во избежание непредвиденных последствий

Модуль не должен зависеть напрямую от других модулей того же слоя или вышележаших слоев

• Концепция известна также как Low Coupling & High Cohesion - для предотвращения неявных связей / сайд-эффектов при разработке и рефакторинге

Ориентирование на потребности бизнеса и пользователя

• Включает в себя также разбиение структуры по бизнес-доменам (т.н. "слайсам")

Для проектирования архитектуры методология предлагает оперировать привычными абстракциями, но в более консистентном и последовательном порядке.

Первый уровень абстрагирования - согласно скоупу влияния

• app - инициализация приложения (init, styles, providers, ...)
• processes - бизнес-процессы приложения управляющие страницами (payment, auth, ...)
• pages - страницы приложения (user-page, ...)
• features - части функциональности приложения (auth-by-oauth, ...)
• entities - бизнес-сущности (viewer, order, ...)
• shared - переиспользуемый инфраструктурный код (UIKit, libs, API, ...)

Второй уровень абстрагирования - согласно бизнес-домену

Правила, по которым код разделяется на слайсы, зависят от конкретного проекта и его бизнес-правил и не определяются методологией

Третий уровень абстрагирования - согласно назначению в реализации

• ui - UI-представление модуля (components, widgets, canvas, ...)
• model - бизнес-логика модуля (store, effects/actions, hooks/contracts, ...)
• lib - вспомогательные библиотеки
• api - логика взаимодействия с API
• config - модуль конфигурации приложения и его окружения

Примечание: В большинстве случаев рекомендуется располагать api и config только в shared-слое

WIP: Нейминг групп временный, и будет определен окончательно ближе к релизу

└── src/
    ├── app/                    # Layer: Приложение
    |                           #
    ├── processes/              # Layer: Процессы (опционально)
    |   ├── {some-process}/     #     Slice: (н-р процесс CartPayment)
    |   |   ├── lib/            #         Segment: Инфраструктурная-логика (хелперы)
    |   |   └── model/          #         Segment: Бизнес-логика
    |   ...                     #
    |                           #
    ├── pages/                  # Layer: Страницы
    |   ├── {some-page}/        #     Slice: (н-р страница ProfilePage)
    |   |   ├── lib/            #         Segment: Инфраструктурная-логика (хелперы)
    |   |   ├── model/          #         Segment: Бизнес-логика
    |   |   └── ui/             #         Segment: UI-логика
    |   ...                     #
    |                           #
    ├── features/               # Layer: Фичи
    |   ├── {some-feature}/     #     Slice: (н-р фича AuthByPhone)
    |   |   ├── lib/            #         Segment: Инфраструктурная-логика (хелперы)
    |   |   ├── model/          #         Segment: Бизнес-логика
    |   |   └── ui/             #         Segment: UI-логика
    |   ...                     #
    |                           #
    ├── entities/               # Layer: Бизнес-сущности
    |   ├── {some-entity}/      #     Slice: (н-р сущность User)
    |   |   ├── lib/            #         Segment: Инфраструктурная-логика (хелперы)
    |   |   ├── model/          #         Segment: Бизнес-логика
    |   |   └── ui/             #         Segment: UI-логика
    |   ...                     #
    |                           #
    ├── shared/                 # Layer: Переиспользуемые ресурсы
    |   ├── api/                #         Segment: Логика запросов к API
    |   ├── config/             #         Segment: Конфигурация приложения
    |   ├── lib/                #         Segment: Инфраструктурная-логика приложения
    |   └── ui/                 #         Segment: UIKit приложения
    |   ...                     #
    |                           #
    └── index.tsx/              #

• Документация методологии

  Get-Started, Concepts, Guides, Reference, About

• Миграция с feature-slices@v1
• Прочие материалы
  • Предыдущие версии методологии: feature-slices, feature-driven
  • Доклад React SPB Meetup #1 - Feature Slices
  • Feature Driven Architecture - Oleg Isonen
  • A feature based approach to React development
  • Why React developers should modularize their applications?
  • How to Organize Your React + Redux Codebase
  • The Humanizing Work Guide to Splitting User Stories (aka "Vetical Slices")

• Дискуссии по методологии
  • Здесь обсуждаются и разбираются реальные примеры применения, вопросы, проблемы, идеи методологии
  • Все это в совокупности влияет на спецификацию, тулкит и в целом - на дальнейшее видение и развитие методологии
  • Т.е. все, чего пока нет в спецификации/тулките, так или иначе обсуждается в github-discussions
• Как можно помочь?
  • ⭐ Оцените нас на GitHub
  • 💫 Важно любое содействие - от фидбека до участия в развитии методологии!