Перейти к содержанию

Архитектурный обзор системы

Контекст

Konstructorium реализован как набор Django-сервисов с общим PostgreSQL и Redis, плюс внешний Telegram-бот для оплаты и выдачи цифровых файлов.

Границы системы

  • Клиентские акторы: веб-клиент, администратор, пользователь Telegram.
  • Внутренние компоненты: 9 API-сервисов и 1 бот.
  • Общая инфраструктура: PostgreSQL, Redis, Docker Compose.

Доменные зоны

  • Identity and Access: auth_service, частично user_service.
  • Catalog and Content: product_service.
  • Commerce and Fulfillment: order_service, order_celery, telegram_bot_service.
  • Community and Moderation: review_service, chat_service, admin_service.
  • Observability (product analytics): analytics_service (ingest), отчёты в admin_service.

Системный контекст (C4 Level 1)

flowchart LR
  buyer["Buyer"] --> webUi["Web UI"]
  seller["Seller"] --> webUi
  adminUser["Administrator"] --> adminUi["Admin UI"]
  tgUser["Telegram User"] --> tgClient["Telegram Client"]

  webUi --> authSvc["auth_service"]
  webUi --> userSvc["user_service"]
  webUi --> productSvc["product_service"]
  webUi --> orderSvc["order_service"]
  webUi --> reviewSvc["review_service"]
  webUi --> chatSvc["chat_service"]
  webUi --> analyticsSvc["analytics_service"]
  adminUi --> adminSvc["admin_service"]
  adminUi --> analyticsSvc

  tgClient --> botSvc["telegram_bot_service"]
  botSvc --> orderSvc
  botSvc --> productSvc

  authSvc --> db["PostgreSQL"]
  userSvc --> db
  productSvc --> db
  orderSvc --> db
  reviewSvc --> db
  chatSvc --> db
  analyticsSvc --> db
  adminSvc --> db
  orderSvc --> redis["Redis"]
  celeryWorker["order_celery"] --> redis

Архитектурные ограничения

  • Межсервисная связность реализована не только через HTTP, но и через прямые импорты Django-приложений/моделей.
  • Общая БД ускоряет разработку, но увеличивает риск каскадных регрессий при изменениях схемы.
  • Отсутствие OpenAPI в исходном состоянии повышает стоимость ручной поддержки API-контрактов.

Master-alignment

Верхнеуровневые архитектурные принципы и RACI определены в Master-документации проекта.

Требование Причина Проверка Артефакт
Архитектурные boundaries не нарушаются без ADR Сдерживание связности и техдолга review breaking changes ADR + architecture docs
Межсервисные контракты синхронизированы Снижение интеграционных инцидентов cross-service smoke QA report
Критичные зависимости отражены в рисках Предсказуемость релизов сверка с risk register governance/risk-register