Skip to main content

Обзор архитектуры

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

Архитектурная модель​

В основе проекта лежит трёхслойная модель:

app ← domain ← data

Каждый слой решает свою задачу и не нарушает границы других слоёв.

  • App — отвечает за пользовательский интерфейс и пользовательские сценарии
  • Domain — содержит бизнес-логику и правила предметной области
  • Data — реализует доступ к данным и внешним источникам

Слой App​

Слой app отвечает за отображение данных и взаимодействие с пользователем.

Зоны ответственности​

  • рендеринг UI
  • управление состоянием интерфейса
  • обработка пользовательских событий
  • навигация и маршрутизация
  • вызов бизнес-сценариев (use-case) из domain

Ограничения​

  • не содержит бизнес-правил
  • не знает о деталях хранения данных
  • не импортирует код из data

Слой Domain​

Слой domain является ядром приложения и описывает предметную область.

Зоны ответственности​

  • бизнес-правила и политики поведения
  • валидация в терминах домена
  • координация бизнес-сценариев (use-case)
  • описание контрактов для внешних зависимостей

Ключевые свойства​

  • независим от UI и инфраструктуры
  • не использует React, HTTP, хранилища
  • работает только с чистыми структурами данных

Слой Data​

Слой data отвечает за взаимодействие с внешними источниками данных.

Зоны ответственности​

  • реализация репозиториев и портов из domain
  • выполнение HTTP-запросов
  • маппинг моделей данных
  • обработка инфраструктурных ошибок
  • кэширование, ретраи

Ограничения​

  • не содержит бизнес-логики
  • не зависит от app
  • использует только контракты из domain/interface

Коммуникация между слоями​

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

  1. app вызывает use-case из domain и repository из data
  2. use-case работает с портами и репозиториями
  3. data реализует эти порты и предоставляет конкретные адаптеры

Таким образом, каждый слой знает только то, что ему необходимо.

Модульность и масштабирование​

Архитектура проекта поддерживает модульный рост:

  • фичи изолированы друг от друга
  • модули имеют явный публичный API
  • новые источники данных подключаются без изменения бизнес-логики
  • UI можно изменять без влияния на domain

Когда менять архитектуру​

Архитектурные изменения допустимы, если:

  • появляется новая предметная область
  • текущая структура перестаёт масштабироваться
  • требуется новый способ взаимодействия с данными

Все изменения архитектуры должны быть:

  • осознанными
  • задокументированными
  • согласованными внутри команды