🇺🇸 English | 🇷🇺 Русский

Архитектура US-GFECD

US-GFECD — это архитектурный подход для realtime-приложений с разделением ответственности.

Клиент (US):

• UI — отвечает за отображение. Содержит элементы (атомарные компоненты), которые читают или изменяют данные.
• Store — управляет состоянием. Отвечает за хранение данных и отправку запросов на сервер.

Сервер (GFECD):

• Gate — входной адаптер. Принимает запросы от клиента и вызывает Flow.
• Flow — оркестратор. Координирует выполнение задач, вызывая Core, Db или Emit.
• Core — бизнес-логика. Чистые функции с правилами и расчётами.
• Db — доступ к данным. Работает с базой данных.
• Emit — исходящие события. Отправляет уведомления клиентам.

Ключевые принципы

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

Общая схема

Схема разделена на две части: клиент (US) и сервер (GFECD). Серые стрелки показывают внутренние связи между слоями. Зелёные стрелки обозначают прямые клиент-серверные взаимодействия: Entity и Invoke отправляют запросы в Gate, Emit отправляет события в Entity.

Слои сервера (GFECD)

Gate

Зачем: отделить протокол (WebSocket/HTTP) от бизнес-логики.

Что делает: принимает запросы, проверяет авторизацию, валидирует входные данные, вызывает Flow.

Что не делает: не содержит бизнес-логики, не работает с БД, не отправляет события.

Flow

Зачем: координировать сложные бизнес-процессы.

Что делает: вызывает Core (логику), Db (данные), Emit (события). Управляет транзакциями.

Что не делает: не содержит бизнес-правил, не импортирует Gate.

Core

Зачем: изолировать правила и расчёты.

Что делает: содержит бизнес-правила, выполняет расчёты и валидацию. Работает с данными без побочных эффектов.

Что не делает: не импортирует Gate, Flow, Db, Emit, не работает с БД.

Db

Зачем: инкапсулировать работу с БД.

Что делает: читает и записывает данные. Отвечает на вопросы (например, isUserInRoom).

Что не делает: не содержит бизнес-логику, не оркестрирует запросы.

Emit

Зачем: отправлять события клиентам.

Что делает: отправляет события через WebSocket, поддерживает комнаты.

Что не делает: не содержит бизнес-логику, не импортирует Gate, Flow, Core, Db.

Слои клиента (US)

UI

Зачем: отделить представление от данных и логики.

Что делает: отображает данные из Store, принимает ввод пользователя, передаёт команды в Store.

Что не делает: не содержит бизнес-логику, не работает с сервером напрямую, не хранит состояние (всё состояние в Store).

Состав:

• Elements — атомарные компоненты без логики (кнопки, карточки, поля ввода). Ничего не знают о Store.
• View — читают данные из Store. Только отображение. Не изменяют данные. Могут использовать Entity для инициализации (подписка на данные).
• Edit — изменяют данные через Store (вызывают Invoke). Не читают данные.
• Page — собирают View, Edit и Elements в страницу.

Store

Зачем: управлять состоянием и синхронизировать его с сервером.

Что делает: хранит данные, обрабатывает запросы, обновляет состояние при ответах от сервера.

Что не делает: не содержит бизнес-логику, не знает о UI.

Состав:

• State — данные и редьюсеры для их изменения. (Рекомендуется выносить редьюсеры в State, но это не обязательно.)
• Entity — объединяет State, инициализацию (загрузка данных) и подписки на обновления от сервера. Управляет жизненным циклом данных (init/clean).
• Invoke — отправка запросов на сервер. Получает ответ, обновляет State через редьюсеры.

Подробнее о реализации Store в клиентской библиотеке: @us-gfecd/client

Потоки данных

Запрос

1. UI → Store (команда).
2. Store → Gate (запрос по сети через Socket.IO v4).
3. Gate → Flow (вызов).
4. Flow → Core (логика) и Db (данные).
5. Flow → Emit (опционально, если нужно уведомить других).
6. Ответ: Flow → Gate → Store → UI.

Событие

1. Серверное событие → Flow.
2. Flow → Emit.
3. Emit → Entity (на клиенте) через Socket.IO v4.
4. Entity → State (обновление).
5. State → UI (перерисовка).