# СДЕ Sarex — типовой контур (пример)

Автогенерация из `example-technology.archimate`. Зелёный — технологический слой, голубой — прикладной. Пунктир с полым треугольником — realization, стрелка — serving, ромб — composition, линия с шариком — assignment, полый ромб — aggregation. Подробнее — в представлении «L1. Как читать схемы». Описание элемента всплывает подсказкой при наведении на блок.

Архитектура типового контура платформы в двух слоях. Технологический: кластер, платформенные компоненты внутри него, внешние системы за периметром и технологические сервисы, которые всё это даёт приложениям. Прикладной: компоненты платформы по смысловым группам, вызовы между ними и зависимость каждого от технологических сервисов. Имена кластера, узлов, доменов и реестра заменены на примеры — конкретная инсталляция задаётся отдельным профилем контура.

Связи не нарисованы от руки, а выведены из манифестов развёртывания: переменных окружения, аннотаций и маршрутов. Исключения оговорены отдельно — внешние интеграции и смысловая группировка приложений заданы профилем, описания компонентов получены чтением исходного кода. Как читать нотацию — представление «L1».

## L1. Как читать схемы

Легенда нотации. Показан настоящий фрагмент модели, подписанный по типам: каждый элемент и каждая линия здесь встречаются на остальных представлениях в том же начертании.

## T1. Технологический слой

Что развёрнуто в кластере и какие технологические сервисы это даёт. Приложения-потребители вынесены в отдельные представления T2 и далее.

## T2. Развёртывание по узлам

Какие группы узлов какие компоненты несут. Вложенность заменяет стрелки: хост внутри группы — composition, приложение — assignment, системное ПО — aggregation. Имена хостов заданы в профиле контура.

## T3. Внешние интеграции

Системы за периметром контура, с которыми платформа обменивается данными, и направление зависимости. Слева — технологические сервисы, которые видят приложения; справа — то, чем эти сервисы обеспечены на стороне заказчика. Схем подключения каталога предприятия четыре, и в конкретном контуре работает одна: каталог напрямую к провайдеру идентификации платформы; каталог через брокер Keycloak; то же с доменным входом по Kerberos, который умеет проверять только брокер; либо служба федерации AD FS поверх того же каталога. Здесь показаны все четыре сразу — при развёртывании лишние узлы из профиля убираются.

## T4. Потребители: Маршрутизация HTTPS-трафика

Сервисом пользуется 21 из 37 приложений контура.

## T5. Потребители: Аутентификация OIDC

Сервисом пользуются 25 из 37 приложений контура.

## T6. Потребители: Управление секретами

Сервисом пользуются 26 из 37 приложений контура.

## T7. Потребители: Реляционное хранилище

Сервисом пользуются 24 из 37 приложений контура.

## T8. Потребители: Кэш

Сервисом пользуются 5 из 37 приложений контура.

## T9. Потребители: Событийная шина

Сервисом пользуются 14 из 37 приложений контура.

## T10. Потребители: Очередь сообщений AMQP

Сервисом пользуются 12 из 37 приложений контура.

## T11. Потребители: Оркестрация процессов BPMN

Сервисом пользуется 1 из 37 приложений контура.

## T12. Потребители: Объектное хранилище

Сервисом пользуются 16 из 37 приложений контура.

## T13. Потребители: Отправка почтовых уведомлений

Сервисом пользуются 6 из 37 приложений контура.

## A0. Карта прикладного слоя

Из чего состоит прикладной слой: 38 компонентов по смысловым группам. Связи здесь намеренно не показаны — на таком числе компонентов они делают схему нечитаемой; для них есть представления A1 и далее. Вложенность означает aggregation: группа объединяет компоненты, но не владеет ими.

## A1. Ядро прикладного слоя

Восемь сервисов с наибольшим числом связей и вызовы между ними. Стрелка идёт от вызываемого к вызывающему (serving): кого лишишься — тот и сломается. Всего в контуре 86 межсервисных связей.

## A2. Зависят от: django

К django обращаются 18 сервисов.

## A3. Зависят от: documentations

К documentations обращаются 11 сервисов.

## A4. Зависят от: eav

К eav обращаются 9 сервисов.

## A5. Зависят от: resources

К resources обращаются 7 сервисов.

## A6. Зависят от: processing

К processing обращаются 6 сервисов.

## A7. Зависят от: iam

К iam обращаются 6 сервисов.

## A8. Зависят от: flows

К flows обращаются 4 сервиса.

## A9. Зависят от: workspaces

К workspaces обращаются 4 сервиса.

## A10. Зависят от: system-log

К system-log обращаются 3 сервиса.

## A11. Зависят от: bim

К bim обращаются 3 сервиса.

## A12. Зависят от: pm

К pm обращаются 3 сервиса.

## P1. Паспорт: documentations

Что нужно, чтобы documentations работал: 7 технологических сервисов и 15 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого documentations — представление A3.

## P2. Паспорт: flows

Что нужно, чтобы flows работал: 7 технологических сервисов и 8 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого flows — представление A8.

## P3. Паспорт: issues

Что нужно, чтобы issues работал: 9 технологических сервисов и 7 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у issues меньше 3, отдельного представления для них нет.

## P4. Паспорт: comparisons

Что нужно, чтобы comparisons работал: 3 технологических сервиса и 6 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у comparisons меньше 3, отдельного представления для них нет.

## P5. Паспорт: django

Что нужно, чтобы django работал: 8 технологических сервисов и 6 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого django — представление A2.

## P6. Паспорт: faas

Что нужно, чтобы faas работал: 0 технологических сервисов и 5 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у faas меньше 3, отдельного представления для них нет.

## P7. Паспорт: transmittal

Что нужно, чтобы transmittal работал: 6 технологических сервисов и 5 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у transmittal меньше 3, отдельного представления для них нет.

## P8. Паспорт: message-hub

Что нужно, чтобы message-hub работал: 5 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у message-hub меньше 3, отдельного представления для них нет.

## P9. Паспорт: pm

Что нужно, чтобы pm работал: 8 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого pm — представление A12.

## P10. Паспорт: processing

Что нужно, чтобы processing работал: 5 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого processing — представление A6.

## P11. Паспорт: rfi

Что нужно, чтобы rfi работал: 7 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у rfi меньше 3, отдельного представления для них нет.

## P12. Паспорт: cde

Что нужно, чтобы cde работал: 5 технологических сервисов и 3 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у cde меньше 3, отдельного представления для них нет.

## P13. Паспорт: notes

Что нужно, чтобы notes работал: 6 технологических сервисов и 3 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у notes меньше 3, отдельного представления для них нет.

## Прикладной слой: описания компонентов

38 компонентов в том же порядке, что и на карте A0. Описания выведены не из манифестов контура, а из исходного кода компонентных репозиториев, и потому проверяются чтением кода, а не сверкой с конфигурацией. То же описание всплывает подсказкой, если задержать курсор на блоке любой схемы.

### Платформа

Общие механизмы, на которые опираются все прикладные домены: единая точка входа в интерфейс, вход и права, справочник атрибутов, рабочие пространства и проекты как контейнеры данных, журнал действий, уведомления, оркестрация процессов.

Почти все связи прикладного слоя ведут сюда, поэтому изменения в этой группе стоят дороже всего: отказ любого её компонента виден сразу во всех доменах, тогда как отказ прикладного сервиса ограничен своей областью.

ams-sync

  Односторонняя синхронизация учётных записей из ядра платформы во внешний провайдер идентификации: созданный или изменённый пользователь вместе с профилем, принадлежностью организации и метаданными появляется в Zitadel, где на этих данных строится авторизация доменных сервисов. Работает консьюмером Kafka-топика, отдельный консольный режим использовался для первичной массовой миграции пользователей и компаний. Входящих вызовов не принимает.

  Стек: Python · консьюмер Kafka (kafka-python) · requests с ретраями · Zitadel Management API.

auth-flow

  Входная точка авторизации платформы: страницы `/login`, `/logout`, `/auth/callback`, `/auth/error` и обработка OIDC-редиректов Zitadel по Authorization Code flow. Полученные токены передаются в оболочку микрофронтендов; бизнес-данных компонент не хранит.

  Стек: TypeScript · React · Webpack 5 · внутренний sdk-js поверх oidc-client · Zitadel (OIDC) · oauth2-proxy в инфраструктуре.

control-interface

  Административный контур платформы (srx-admin): управление пользователями, ролями, атрибутами, подразделениями, проектами и функциональными группами, а также реестром активов компании с правами доступа. Отдельный крупный сценарий — пакетный импорт активов из XLSX со статусами заданий и отчётами об ошибках.

  Стек: TypeScript · React · MobX · Material-UI и ui-kit · Webpack 5 Module Federation · монорепозиторий npm-workspaces; собственного хранилища нет.

django

  Легаси-монолит и ядро продукта: компании, пользователи, роли и подрядчики, объекты строительства, миссии аэрофотосъёмки, ортофотопланы, облака точек и поверхности, измерения, аналитика с дашбордами и метриками, карта, ТОиР, уведомления и журнал действий. Здесь же — основной SPA-хост, в который встраиваются все микрофронтенды платформы.

  Стек: Python · Django + DRF · django-guardian · channels · Celery + Redis · Kafka · PostgreSQL, ClickHouse, MongoDB, S3 · фронтенд на TypeScript/React/MobX (Module Federation, PWA).

eav

  Универсальная модель «сущность — атрибут — значение»: пользовательские атрибуты, их типы, схемы и справочники, расширяющие любые доменные объекты без изменения схемы БД. Второй блок — иерархический классификатор активов объекта (WBS-дерево) с импортом и экспортом через Excel.

  Стек: Python · Django + DRF · django-filter · Celery · PostgreSQL (в том числе сырой SQL для иерархии) · pandas + openpyxl · контракты protobuf.

faas

  Логическое имя слоя эфемерных вычислительных функций — одноразовых job-контейнеров, запускаемых движком workflow поверх Kubernetes. Отдельного репозитория и кодовой базы не найдено; значение компонента требует уточнения у команды платформы.

  Стек: Предположительно Kubernetes Job и воркеры RabbitMQ поверх Docker-образов на Python и Go; собственной кодовой базы не найдено, стек требует подтверждения.

flows

  Маршруты согласования проектной документации: маршрут из шагов с назначенными согласующими, ревью документов, решения участников, сроки по рабочим дням и очередь задач согласующего. Публикует события согласования в Kafka и умеет автоматически инициировать трансмиттал после завершения маршрута.

  Стек: Python · FastAPI · SQLAlchemy + Alembic · PostgreSQL (JSONB) · Celery · FastStream + Kafka · фронтенд на TypeScript/React/MobX (rsbuild + Module Federation).

iam

  Платформенный IAM: иерархия ресурсов, компании, пользователи, сервисные аккаунты и права по модели ReBAC (SpiceDB). Отвечает на вопросы «какие права у пользователя на ресурс» и «какие ресурсы доступны пользователю», на которые опираются остальные сервисы; пользователи заводятся во внешнем Zitadel.

  Стек: Go, гексагональная архитектура · SpiceDB по gRPC с собственным Postgres-datastore · PostgreSQL · S3 · Kafka · Zitadel Management API · Helm с Istio.

message-hub

  Событийный хаб домена планирования: принимает события Kafka и выполняет побочные действия — пересчёт аналитики, обновление атрибутов, письма, экспорты, системный журнал, автопланирование, синхронизацию проектов и ресурсов. Транслирует изменения в браузер по WebSocket, обеспечивая живое обновление доски проекта.

  Стек: Python · FastStream + Kafka (aiokafka) · python-socketio с Redis · SQLAlchemy Core с сырым SQL к PostgreSQL · S3 · Jinja2 для писем.

projects

  Витрина проектов и карточка проекта — верхнеуровневый вход пользователя в платформу: атрибуты, местоположение, фотографии, группировки и настраиваемые вкладки с разделами-виджетами. Агрегирует показатели остальных модулей, включая встраивание внешней аналитики.

  Стек: Python · FastAPI · async SQLAlchemy 2.0 + Alembic · PostgreSQL (JSONB) · S3 · фронтенд на React/MobX с TanStack Query и leaflet · встраивание Superset.

subscriptions

  Подписки на изменения объектов и рассылка уведомлений по e-mail, SMTP/Mailgun и Telegram с периодичностью от мгновенной до еженедельной. Источник изменений — не брокер, а периодический опрос журнала system-log; тексты формируются по шаблонам, привязанным к модели и типу события.

  Стек: Python · Django + DRF · PostgreSQL с PostGIS и TimescaleDB · SMTP и Mailgun · python-telegram-bot · Jinja2 · OpenTelemetry.

system-log

  Централизованный журнал системных событий (аудит) всей платформы: кто, что и над каким объектом сделал, с метаданными, ресурсом и компанией. Обеспечивает прослеживаемость изменений и служит источником событий для механизма подписок и уведомлений.

  Стек: Go · Fiber · pgx + squirrel с миграциями на старте · PostgreSQL · Kafka через sarama (опционально) · отдельный воркер с cron · OpenTelemetry.

workspaces

  Рабочее пространство — сцена, в которой пользователь одновременно работает с BIM-моделями, облаками точек, PDF-чертежами и панорамами объекта, настраивает отображение и сохраняет именованные состояния. Поддерживает установку прикладных модулей компании как федеративных приложений внутри сцены и архивирование данных при закрытии этапов.

  Стек: Go (gorilla/mux, go-pg, Prometheus, Sentry, JWT на RSA) · PostgreSQL · фронтенд на TypeScript/React/MobX с viewer (Module Federation), кеш в IndexedDB · тесты Cypress и Jest.

### Управление проектом

Планирование и учёт: календарно-сетевые планы, договоры и обязательства по ним, справочник ресурсов, рабочие заметки.

Группа потребляет данные остальных доменов чаще, чем отдаёт: план и договор ссылаются на документы, замечания и полевые измерения, обратные ссылки редки.

contracts

  Реестр договоров компании: номер, подрядчик, сроки, стоимость, привязка к проекту или объекту. Даёт коммерческий контур поверх производственных данных; на договор, в частности, ссылается предписание.

  Стек: Go · Fiber v3 · pgx + squirrel · PostgreSQL (JSONB) · фронтенд на TypeScript/React/MobX по Feature-Sliced Design.

notes

  Заметки и примечания на объектах проекта: пометка на 2D-чертеже или в 3D-модели со сроком, цветом, фотографиями, вложениями и связями с сущностями разных сервисов. Поддерживает отправку скриншота вида и формирование документа по заметке; применяется при авторском надзоре и строительном контроле.

  Стек: Python · FastAPI · SQLAlchemy + Alembic · PostgreSQL с полнотекстовым поиском · фронтенд на TypeScript/React/MobX/Material-UI.

pm

  Календарно-сетевое планирование: иерархия задач, длительности, связи предшествования, календари, базовые планы, факт и проценты выполнения, ресурсы и назначения. Импорт графиков из MS Project, Primavera и XLSX, работа на диаграмме Ганта, экспорт в PDF, асинхронное автопланирование и пересчёт.

  Стек: Python · Django 5 + DRF, целевой стиль — FastAPI с async SQLAlchemy · PostgreSQL с триггерами · ClickHouse · S3 · Celery + Redis · Kafka · pandas, парсеры MS Project и Primavera · фронтенд на React/MobX.

resources

  Единый реестр ресурсов платформы — иерархия объектов строительства (проект, объект, участок и ниже) с типами, географическим положением, кодами и правами доступа. Идентификатор ресурса служит сквозным ключом проекта во всех остальных сервисах, а сам реестр — общей точкой проверки прав, поэтому это один из самых востребованных компонентов контура. Интеграция только синхронная, по HTTP.

  Стек: Python · Django + DRF · django-filter · PostgreSQL с ltree и PostGIS · фронтенд в отдельном репозитории.

### Документы и общая среда данных

Ядро CDE: хранение документов и их версий, связи между документами, вложения, комплекты передачи, чертежи и трёхмерные модели, подготовка САПР-моделей к просмотру, проверка штампов.

Самая нагруженная группа по числу входящих ссылок — на документ ссылается почти каждый прикладной сценарий. Хранилище документов здесь же является и самым связанным компонентом всей платформы.

attachments

  Универсальное хранилище файловых вложений к любым сущностям платформы: файл кладётся в S3, метаданные — в PostgreSQL, привязка полиморфная («имя модели + идентификатор экземпляра»). Скачивание идёт по временным подписанным ссылкам напрямую из объектного хранилища.

  Стек: Python · FastAPI · PostgreSQL (psycopg2, сырой SQL; Alembic только для схемы) · S3 через boto3 · OpenTelemetry.

bim

  Ядро работы с информационными моделями: хранит BIM-модели проекта, дерево элементов, их свойства и статусную модель хода строительства (в том числе корпоративные шаблоны статусов с цветами и переходами). Питает раскраску моделей во вьюере, фильтрацию элементов и отчётность о проценте готовности.

  Стек: Go (go-pg, gorilla/mux, Prometheus) и легаси-часть на Python/Flask · PostgreSQL с шардированием и партиционированием · S3 · джоб metadata-inserter на Go.

cde

  Среда общих данных (CDE): документы, версии, комплекты, права, штампы, QR-метки, электронные подписи, публичные ссылки и changelog. Публикует доменные события через transactional outbox в Kafka и постепенно принимает на себя мутирующие вызовы legacy-сервисов документации.

  Стек: Go (Fiber, go-pg) · PostgreSQL · S3/MinIO · Valkey · Kafka (transactional outbox) · Camunda 8 / Zeebe · OpenTelemetry.

document-link

  Публичная страница выданной наружу ссылки на документ: получатель без учётной записи видит карточку документа и скачивает файл. Собственного бэкенда нет — данные отдаёт публичный эндпоинт documentations, срок действия ограничен JWT ссылки.

  Стек: TypeScript · Next.js (app router) · React · SWR · Tailwind; собственного бэкенда нет.

documentations

  Рабочая среда документации проекта: диски, дерево папок, документы с версиями, страницами, атрибутами, правами и связями; штампы, ЭЦП, подписки, корзина, публичные ссылки. Отвечает также за постановку загруженных инженерных форматов в очередь конвертации. Домен находится в миграции — мутирующие операции проксируются в cde.

  Стек: Go (go-pg, Fiber, swaggo) · PostgreSQL · S3 с многочастной загрузкой · Valkey · RabbitMQ · Mailgun/SMTP · фронтенд на TypeScript/React/MobX.

drawings

  Серверная часть сечений: хранит поперечные сечения по поверхностям и облакам точек и задания на их экспорт, принимает результат асинхронной выгрузки по webhook. Применяется при исполнительной съёмке и контроле выполненных объёмов.

  Стек: Go · gorilla/mux · go-pg с миграциями · PostgreSQL · внутренние библиотеки gotools и sdk-go · Prometheus.

stamp-verification

  Публичная страница проверки подлинности документа по QR-штампу: сканирование кода с бумажной или PDF-копии открывает карточку с документом, страницей и его актуальным состоянием, включая статус согласования. Авторизация не требуется; серверная часть — публичный эндпоинт documentations.

  Стек: Статический сайт без сборщика: HTML, vanilla JS, moment.js; серверная часть — Go (gorilla/mux, go-pg, PostgreSQL) в составе documentation-api.

transmittal

  Формальная передача комплектов документации между участниками — сопроводительное письмо с составом, получателями, сроком и результатом приёма или отклонения. По завершении формируется акт передачи в PDF; есть шаблоны трансмитталов и связь с согласованиями, замыкающая цикл «выдал документацию → получил замечания».

  Стек: Python · FastAPI · async SQLAlchemy + Alembic · PostgreSQL · S3 · taskiq + RabbitMQ · Jinja2 с собственным конвертером HTML в PDF · Mailgun и SMTP · фронтенд на React/MobX (Module Federation).

Конвертер BIM-моделей

  Подготовка исходных САПР-моделей (IFC, NWD и другие форматы Autodesk) к просмотру и анализу: облегчённая геометрия glTF/`.s3d` плюс структурированный набор свойств, категорий и материалов элементов. Обязательное звено между загрузкой документа в CDE и появлением работоспособной модели в интерфейсе; работает как эфемерный джоб и как постоянный воркер RPC.

  Стек: Ядро на Python с ifcopenshell и NumPy · обвязка и воркеры на Go · RabbitMQ (RPC) · S3 · Docker · плагин Navisworks на C#/.NET (SharpGLTF) · форматы IFC и NWD в glTF/GLB, `.s3d` и JSON свойств.

### Контроль качества

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

Группа однородна по устройству — почти каждый её сервис читает документ, пишет запись о несоответствии и поднимает процесс в оркестраторе, — поэтому её компоненты сильнее прочих зависят от домена документов и от платформенных процессов.

checklists

  Шаблоны проверок (чек-листы из шагов и типизированных элементов ввода) и результаты их заполнения. Результат привязывается к любой сущности платформы через пару «тип сущности + идентификатор» и может блокироваться после согласования по вызову из flows.

  Стек: Python · FastAPI · Piccolo ORM с админкой · PostgreSQL (JSONB) · собственный JWT-middleware · OpenTelemetry.

comparisons

  Сравнение проектных данных и выявление отклонений: облако точек к облаку, облако к модели, PDF к PDF, BIM к BIM, расчёт отклонений. Тяжёлые вычисления делегируются движку workflow, результат раскладывается на элементы и изменения, доступные для фильтрации и верификации инженером.

  Стек: Go (Fiber, go-pg) · PostgreSQL · Docker-образы задач в реестре · фронтенд на TypeScript/React/MobX/Material-UI (Module Federation).

inspections

  События и проверки на объекте: планирование осмотров с типом, датой, ответственными, локацией и настраиваемыми атрибутами, контроль занятости исполнителей, история изменений и выгрузка реестра в XLSX. Отдельная подсистема — правила доступности и идемпотентное бронирование слотов для выездов и приёмок.

  Стек: Python · FastAPI · Piccolo ORM с админкой · PostgreSQL (JSONB, триггеры, advisory-локи) · FastStream + Kafka · фронтенд на React/MobX с DevExpress Scheduler.

issues

  Сервис замечаний строительного контроля: типы, настраиваемые статусные модели с правами на переходы, ответственные, комментарии, фото-вложения, атрибуты EAV и история изменений. Включает выпуск предписаний, выгрузку реестров в XLSX и PDF и рассылку уведомлений. Один бэкенд обслуживает также компоненты remarks и prescriptions.

  Стек: Python · Django + DRF · PostgreSQL с полнотекстовым поиском · Celery + Redis · Kafka · S3 · pandas и ReportLab для XLSX и PDF · SimpleJWT с Zitadel.

prescriptions

  Выдача предписаний подрядчику по результатам строительного контроля: предписание собирается из замечаний, привязывается к договору, подрядчику и объекту, получает номер и проходит согласование по статусам. Официальный документ формируется по шаблону движком workflow; бэкенд — приложение внутри issues.

  Стек: Python · Django + DRF · PostgreSQL (приложение внутри бэкенда issues) · генерация документов движком workflow · фронтенд на React/MobX (rsbuild + Module Federation).

remarks

  Пользовательский модуль работы с замечаниями (UI): пин на чертеже, в ячейке XLSX или на задаче графика, описание, срок, ответственные, вложения и пометки поверх листа, табличное и списочное представления, фильтры, массовое редактирование и экспорт. Собственный бэкенд архивирован — модуль работает поверх issues.

  Стек: TypeScript · React · MobX · Material-UI · TanStack Table и Virtual; серверная часть — стек issues.

reviews

  Рабочее место согласующего: очередь задач с приоритетами и сроками, просмотр документа, пометки и замечания, заполнение чек-листов и вынесение решения (согласовано / с замечаниями / отклонено). Ключевой этап между выпуском версии документа и выдачей её «в производство работ»; бэкенд общий с flows.

  Стек: TypeScript · React · MobX · rsbuild + Module Federation; серверная часть — стек flows, экспорт отчётов вынесен в отдельный сервис.

rfi

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

  Стек: Python · Django 5.1 + DRF · django-filter · PostgreSQL · Celery · SimpleJWT с Zitadel · фронтенд на TypeScript/React/MobX (rsbuild + Module Federation).

### Полевые данные

Данные, приходящие со стройплощадки: замеры, привязка к местности, сечения, а также обработка тяжёлых входных файлов.

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

cross-section

  Инструмент построения поперечных сечений по облакам точек и BIM-документам прямо во вьюере, с сохранением сечений, цветовой легендой документов и экспортом в DWG. Применяется при обмере и контроле построенного; серверная часть — drawings.

  Стек: TypeScript · React · MobX · pixi-viewer · джоб экспорта в DWG на Go с Python-генератором · PostgreSQL · объектное хранилище.

mapper

  Агрегирующий сервис (BFF), склеивающий данные нескольких API в один ответ для интерфейса: реестр документов диска вместе с состоянием согласования и заметки вместе с их связями. Собственной доменной модели и базы не имеет, ответы кеширует в Redis.

  Стек: Python · FastAPI · httpx с ретраями · Redis/RedisJSON как кеш; собственной БД нет.

measurements

  Геопространственные измерения по материалам аэросъёмки: высота и температура в точке, профиль вдоль ломаной, расчёт объёма по контуру и разности объёмов между съёмками, метаданные растров и пересчёт координат. Stateless-сервис без собственной БД, читающий GeoTIFF напрямую из объектного хранилища.

  Стек: Python · FastAPI · GDAL, pyproj, NumPy, OpenCV, SciPy · чтение GeoTIFF из S3 через boto3; собственной БД нет.

processing

  Фабрика тяжёлых вычислений платформы: движок workflow исполняет граф задач, каждая из которых запускается отдельным контейнером (Kubernetes Job или воркер через RabbitMQ). Через него работают конвертация форматов, сравнения, экспорт в DWG и генерация документов; отдельный интерфейс даёт мониторинг, логи, отмену и перезапуск задач.

  Стек: Go (pgx, go-pg, zap) · PostgreSQL · Kubernetes client-go для джобов · RabbitMQ для сторонних воркеров · джобы на Python (boto3, внутренняя workflows-tools) · фронтенд на React/MobX.