Топология сервисов
Зачем нужно
Документ фиксирует, какие сервисы реально существуют в продакшене, какие у них границы и как они общаются.
Принцип разбиения
Один домен = один backend-сервис + один фронтенд (либо публичный сайт, либо рабочий кабинет, либо админка). Дробить домен на микросервисы можно только через ADR.
Multi-tenancy на старте моделируется через access scopes и actor context, без отдельного tenant_id в каждой таблице. Это закреплено в ADR-034.
Сервисы
| Сервис | Тип | Назначение |
|---|---|---|
identity-api | backend | identity домен, OAuth-сервер |
identity-admin-web | frontend | админка identity и общие платформенные настройки; UI над platform reference-data, permissions catalog и feature flags |
storefront-web | frontend (SSR/SSG) | публична я витрина |
storefront-api | backend | админка витрины, формы, leads, public read-model |
crm-api | backend | CRM домен |
crm-web | frontend | рабочий кабинет CRM/менеджеров |
lms-api | backend | LMS домен |
lms-web | frontend | учебный кабинет (ученик, родитель, преподаватель) |
task-bank-api | backend | банк задач |
task-bank-web | frontend | редактор и каталог задач (внутренний) |
competitions-api | backend | олимпиады |
competitions-web | frontend | кабинет внешнего преподавателя и участника |
management-api | backend | management домен, аналитика, цели, диагностика |
management-web | frontend | управленческий dashboard |
events-bus | инфраструктура | шина доменных событий |
gateway | reverse proxy | публичный API gateway (Nginx/Traefik) |
redis | инфраструктура | кэш, сессии |
postgres | инфраструктура | основная БД (per-сервис) |
Каждый backend-сервис имеет свою отдельную PostgreSQL-БД (database per service).
identity-api временно хостит platform reference-data tables и endpoints до выделения отдельного platform-service. Это runtime-размещение, а не перенос ownership из platform в identity.
Окружения
| Окружение | Назначение |
|---|---|
local | dev на машине разработчика, Docker Compose |
dev | общее интеграционное окружение |
staging | предрелизное, идентичное prod |
prod | продакшен |
Промежуточные окружения создаются по запросу через CI.
Маршрутизация
- Публичный домен
https://systematika.tld/— storefront-web. https://app.systematika.tld/— учебный/рабочий кабинет (lms-web, crm-web, management-web, task-bank-web, competitions-web; маршрутизация по поддоменам или префиксам).https://id.systematika.tld/— identity (auth, OAuth screens, профиль).https://api.systematika.tld/— единый API gateway, маршрутизирует по префиксу/api/v2/<domain>/...на сервис домена.
Префикс API: /api/v2/<domain>/.... Версионирование описано в api-conventions.md.
Внешние зависимости
| Зависимость | Назначение |
|---|---|
| Email transport | SMTP/SES/Mailgun (через identity transports registry) |
| SMS transport | внешний провайдер |
| Payment provider | webhook идёт в crm-api/payments/provider-webhook/{provider} |
| Object storage | S3 или MinIO для файлов |
| Observability | Grafana stack (Prometheus, Loki, Tempo), Sentry |
Доступ между сервисами
- Сервисы не ходят в чужие БД.
- Online-чтение чужих данных — только через API владельца с service token.
- Долгоживущее состояние — через подписку на события.
- Service-to-service токены выдаются identity authorization server по client_credentials grant с scoped permissions.
Что запрещено
- Один сервис на два домена.
- Прямой SQL-доступ в чужую БД.
- Дублирование canonical-данных без описанной интеграции.
- Развертывание сервиса без observability и health checks.