Перейти к основному содержимому

Основы

Предупреждение

Здесь представлена лишь основная информация по методологии

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

Concepts

Public API

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

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

Isolation

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

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

Needs driven

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

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

Abstractions

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

Layers

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

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

Slices

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

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

Segments

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

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

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

Structure

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

См. также

[01/12] logo-mini