diff --git a/docs/architecture/README.md b/docs/architecture/README.md
index 136eaf3..ef2f5ea 100644
--- a/docs/architecture/README.md
+++ b/docs/architecture/README.md
@@ -10,7 +10,7 @@
|---|---|---|
| `example-technology.archimate` | нативный формат [Archi](https://www.archimatetool.com/) | десктопный Archi: File → Open |
| `example-technology.xml` | The Open Group ArchiMate Model Exchange File Format 3.1 | любой инструмент с импортом Open Exchange, в том числе archi-online.com: **Import, save, and create models** → Open Exchange |
-| `preview.html` | SVG-рендер всех представлений | любой браузер, без установки чего-либо |
+| `preview.html` | SVG-рендер всех представлений плюс справочник компонентов прикладного слоя | любой браузер, без установки чего-либо |
| `matrix.example.json` | снимок матрицы «приложение → технологический сервис» | вход для сборки |
| `calls.example.json` | снимок графа межсервисных вызовов | вход для сборки |
| `app-summaries.md` | короткие описания компонентов прикладного слоя (1–3 предложения) | вход для сборки; попадает в поле `Documentation` модели |
@@ -30,6 +30,8 @@
| A2–A12 | По представлению на сервис с тремя и более потребителями: кто от него зависит |
| P1–P13 | Паспорт сервиса — зеркало к A2–A12: не «кто сломается без него», а «без чего не работает он сам» |
+`preview.html` показывает не только схемы. Сверху — оглавление по всем представлениям, внизу — справочник прикладного слоя: описания всех компонентов, разложенные по тем же смысловым группам, что и на карте A0. Описания лежат в модели (поле `Documentation`), но на схемах их не видно — там помещается только имя, поэтому то же описание всплывает подсказкой при наведении на любой блок любой схемы. В Archi эти же тексты видны в панели свойств.
+
Направление связи — как принято в ArchiMate: стрелка идёт от вызываемого к вызывающему (serving). Читается как «кого лишишься — тот и сломается». Тот же вопрос с другой стороны — представления P: что нужно самому сервису, чтобы работать.
Разбиение по сервисам сделано осознанно: 152 связи «технологический сервис → приложение» и 86 межсервисных вызовов на одной схеме нечитаемы. В модели они лежат одним набором, представления — это срезы.
diff --git a/docs/architecture/contour-profile.example.json b/docs/architecture/contour-profile.example.json
index 8c10691..db1dcb8 100644
--- a/docs/architecture/contour-profile.example.json
+++ b/docs/architecture/contour-profile.example.json
@@ -2,7 +2,7 @@
"_комментарий": "Профиль контура: всё, что зависит от конкретной инсталляции. Значения здесь — ПРИМЕР. Для реального контура скопируйте файл, подставьте настоящие имена и держите копию вне репозитория. Поля doc попадают в Documentation элемента и видны в Archi.",
"model": {
"name": "СДЕ Sarex — типовой контур (пример)",
- "purpose": "Технологический слой типового контура. Имена кластера, узлов, доменов и реестра заменены на примеры. Прикладной слой присутствует как потребители технологических сервисов и как состав групп узлов; межсервисные связи приложений моделируются отдельно."
+ "purpose": "Архитектура типового контура платформы в двух слоях. Технологический: кластер, платформенные компоненты внутри него, внешние системы за периметром и технологические сервисы, которые всё это даёт приложениям. Прикладной: компоненты платформы по смысловым группам, вызовы между ними и зависимость каждого от технологических сервисов. Имена кластера, узлов, доменов и реестра заменены на примеры — конкретная инсталляция задаётся отдельным профилем контура.\n\nСвязи не нарисованы от руки, а выведены из манифестов развёртывания: переменных окружения, аннотаций и маршрутов. Исключения оговорены отдельно — внешние интеграции и смысловая группировка приложений заданы профилем, описания компонентов получены чтением исходного кода. Как читать нотацию — представление «L1»."
},
"cluster": {
"name": "Кластер k8s-prod",
diff --git a/docs/architecture/example-technology.archimate b/docs/architecture/example-technology.archimate
index a5adee1..e726c04 100644
--- a/docs/architecture/example-technology.archimate
+++ b/docs/architecture/example-technology.archimate
@@ -1,5 +1,8 @@
+ Архитектура типового контура платформы в двух слоях. Технологический: кластер, платформенные компоненты внутри него, внешние системы за периметром и технологические сервисы, которые всё это даёт приложениям. Прикладной: компоненты платформы по смысловым группам, вызовы между ними и зависимость каждого от технологических сервисов. Имена кластера, узлов, доменов и реестра заменены на примеры — конкретная инсталляция задаётся отдельным профилем контура.
+
+Связи не нарисованы от руки, а выведены из манифестов развёртывания: переменных окружения, аннотаций и маршрутов. Исключения оговорены отдельно — внешние интеграции и смысловая группировка приложений заданы профилем, описания компонентов получены чтением исходного кода. Как читать нотацию — представление «L1».
@@ -79,7 +82,7 @@
Стек: Python · Django + DRF · django-filter · Celery · PostgreSQL (в том числе сырой SQL для иерархии) · pandas + openpyxl · контракты protobuf.
- Логическое имя слоя эфемерных вычислительных функций.
+ Логическое имя слоя эфемерных вычислительных функций — одноразовых job-контейнеров, запускаемых движком workflow поверх Kubernetes. Отдельного репозитория и кодовой базы не найдено; значение компонента требует уточнения у команды платформы.
Стек: Предположительно Kubernetes Job и воркеры RabbitMQ поверх Docker-образов на Python и Go; собственной кодовой базы не найдено, стек требует подтверждения.
@@ -198,7 +201,7 @@
Flux CD — набор контроллеров Kubernetes, реализующий подход GitOps: вся система описана декларативно и находится под контролем версий, а автоматика непрерывно приводит развёрнутое окружение в соответствие состоянию, заданному в Git. Контроллеры с заданным интервалом сравнивают фактическое состояние ресурсов с желаемым и применяют расхождения. Основные ресурсы: GitRepository описывает источник, Kustomization — набор манифестов для согласования, HelmRelease — развёртывание Helm-чарта.
-Кластер Kubernetes, в котором работает вся платформа. Состав задаётся одним файлом clusters/<контур>/kustomization.yaml — плоским списком инфраструктурных компонентов и приложений; он же является источником истины о том, что развёрнуто. Доставка изменений — GitOps через FluxCD v2: Flux читает манифесты из Git-сервера контура и приводит кластер к описанному состоянию, ручной kubectl apply в нормальном процессе не используется. Прикладные сервисы ставятся не собственными чартами, а одним общим universal-chart, что делает их конфигурацию единообразной.
+Кластер Kubernetes, в котором работает вся платформа. Состав задаётся одним файлом clusters/<контур>/kustomization.yaml — плоским списком инфраструктурных компонентов и приложений; он же является источником истины о том, что развёрнуто. Доставка изменений — GitOps через FluxCD v2: Flux читает манифесты из Git-сервера контура и приводит кластер к описанному состоянию, ручной kubectl apply в нормальном процессе не используется. Прикладные сервисы ставятся не собственными чартами, а одним общим universal-chart, что делает их конфигурацию единообразной.
Istio — открытый service mesh, который прозрачно накладывается на существующие распределённые приложения и централизованно управляет взаимодействием сервисов, не требуя изменений в коде. Ingress-шлюз — это компонент плоскости данных Istio на границе mesh: он принимает внешний трафик, терминирует TLS и передаёт запросы внутрь по правилам, заданным ресурсами Gateway и VirtualService.
@@ -223,7 +226,7 @@
HashiCorp Vault — централизованная система управления секретами: учётными данными, ключами шифрования и сертификатами, с аудитом всех обращений. Работает по схеме «клиент аутентифицируется — получает токен, связанный с набором политик — обращается к секретам по путям — Vault проверяет права и записывает обращение в журнал независимо от исхода». Модульная архитектура позволяет подключать разные способы аутентификации и разные хранилища секретов, включая выдачу временных учётных данных к базам данных.
-Единственный механизм доставки секретов приложениям. Секреты не лежат в манифестах и не хранятся в Git: под получает их через sidecar Agent Injector, который аутентифицируется в Vault по service account пода и монтирует значения из пути вида secrets/data/apps/<приложение>/postgres. Ролью и service account служит имя приложения — соглашение единообразно для всех сервисов. Трафик к Vault выведен из-под sidecar-прокси Istio отдельной аннотацией, иначе инициализация пода не проходит.
+Единственный механизм доставки секретов приложениям. Секреты не лежат в манифестах и не хранятся в Git: под получает их через sidecar Agent Injector, который аутентифицируется в Vault по service account пода и монтирует значения из пути вида secrets/data/apps/<приложение>/postgres. Ролью и service account служит имя приложения — соглашение единообразно для всех сервисов. Трафик к Vault выведен из-под sidecar-прокси Istio отдельной аннотацией, иначе инициализация пода не проходит.PostgreSQL — объектно-реляционная СУБД с открытым исходным кодом и почти сорокалетней историей развития. Соответствует требованиям ACID, использует многоверсионное управление конкурентным доступом (MVCC) и покрывает не менее 170 из 177 обязательных возможностей ядра стандарта SQL:2023. Поддерживает широкий набор типов данных, включая JSON и JSONB, геометрические и пользовательские типы, а также расширения — хранимые процедуры на нескольких языках, обёртки сторонних источников данных и геопространственное расширение PostGIS.
@@ -772,35 +775,36 @@
+ Легенда нотации. Показан настоящий фрагмент модели, подписанный по типам: каждый элемент и каждая линия здесь встречаются на остальных представлениях в том же начертании.Стрелка serving читается не как «кто кого вызывает», а как «кто без кого не работает»: она идёт от обслуживающего к обслуживаемому. Направление выбрано так потому, что от схемы обычно нужен ответ на вопрос «что откажет, если убрать этот элемент», — и он читается по стрелкам вперёд.
-
+ Узел (Node) — вычислительная среда: кластер, группа серверов или отдельный хост. Ромб на линии — composition: узел состоит из этого, и отдельно от узла содержимое не существует.
-
+
-
+ Системное ПО (System Software) — платформенный компонент внутри узла. Пунктир с полым треугольником — realization: компонент реализует технологический сервис.
-
+
-
+ Технологический сервис (Technology Service) — что платформа даёт приложениям, без указания, чем именно это сделано. Приложение зависит от сервиса, а не от конкретного продукта под ним.
-
+
@@ -809,7 +813,7 @@
-
+
@@ -817,7 +821,7 @@
-
+
@@ -825,7 +829,7 @@
-
+
@@ -838,84 +842,84 @@
Артефакт (Artifact) — то, что физически лежит в хранилище: файл, образ контейнера, дистрибутив.
- Легенда нотации. Показан настоящий фрагмент модели, подписанный по типам: каждый элемент и каждая линия здесь встречаются на остальных представлениях в том же начертании.
-
+ Что развёрнуто в кластере и какие технологические сервисы это даёт. Приложения-потребители вынесены в отдельные представления T2 и далее.
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
@@ -941,19 +945,19 @@
-
+
-
+
-
+
-
+
@@ -963,33 +967,33 @@
-
+
-
+
-
+
-
+
-
+
-
-
-
+
+
+
-
+
-
+
- Что развёрнуто в кластере и какие технологические сервисы это даёт. Приложения-потребители вынесены в отдельные представления T2 и далее.
+ Какие группы узлов какие компоненты несут. Вложенность заменяет стрелки: хост внутри группы — composition, приложение — assignment, системное ПО — aggregation. Имена хостов заданы в профиле контура.
@@ -1164,758 +1168,758 @@
- Какие группы узлов какие компоненты несут. Вложенность заменяет стрелки: хост внутри группы — composition, приложение — assignment, системное ПО — aggregation. Имена хостов заданы в профиле контура.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Системы за периметром контура, с которыми платформа обменивается данными, и направление зависимости. Слева — технологические сервисы, которые видят приложения; справа — то, чем эти сервисы обеспечены на стороне заказчика.
Схем подключения каталога предприятия четыре, и в конкретном контуре работает одна: каталог напрямую к провайдеру идентификации платформы; каталог через брокер Keycloak; то же с доменным входом по Kerberos, который умеет проверять только брокер; либо служба федерации AD FS поверх того же каталога. Здесь показаны все четыре сразу — при развёртывании лишние узлы из профиля убираются.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+ Сервисом пользуется 21 из 37 приложений контура.
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Сервисом пользуется 21 из 37 приложений контура.
-
+ Сервисом пользуются 25 из 37 приложений контура.
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Сервисом пользуются 25 из 37 приложений контура.
-
+ Сервисом пользуются 26 из 37 приложений контура.
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Сервисом пользуются 26 из 37 приложений контура.
-
+ Сервисом пользуются 24 из 37 приложений контура.
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Сервисом пользуются 24 из 37 приложений контура.
-
+ Сервисом пользуются 5 из 37 приложений контура.
+
-
-
-
-
-
+
+
+
+
+
-
+
-
+
-
+
-
+
-
+
-
+
- Сервисом пользуются 5 из 37 приложений контура.
-
+ Сервисом пользуются 14 из 37 приложений контура.
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Сервисом пользуются 14 из 37 приложений контура.
-
+ Сервисом пользуются 12 из 37 приложений контура.
+
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Сервисом пользуются 12 из 37 приложений контура.
-
+ Сервисом пользуется 1 из 37 приложений контура.
+
-
+
-
+
-
+
- Сервисом пользуется 1 из 37 приложений контура.
-
+ Сервисом пользуются 16 из 37 приложений контура.
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Сервисом пользуются 16 из 37 приложений контура.
-
+ Сервисом пользуются 6 из 37 приложений контура.
+
-
-
-
-
-
-
+
+
+
+
+
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Сервисом пользуются 6 из 37 приложений контура.
+ Из чего состоит прикладной слой: 38 компонентов по смысловым группам. Связи здесь намеренно не показаны — на таком числе компонентов они делают схему нечитаемой; для них есть представления A1 и далее. Вложенность означает aggregation: группа объединяет компоненты, но не владеет ими.
@@ -2045,1102 +2049,1100 @@
- Из чего состоит прикладной слой: 38 компонентов по смысловым группам. Связи здесь намеренно не показаны — на таком числе компонентов они делают схему нечитаемой; для них есть представления A1 и далее. Вложенность означает aggregation: группа объединяет компоненты, но не владеет ими.
-
+ Восемь сервисов с наибольшим числом связей и вызовы между ними. Стрелка идёт от вызываемого к вызывающему (serving): кого лишишься — тот и сломается. Всего в контуре 86 межсервисных связей.
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
-
-
+
+
+
+
+
+
-
+
-
-
+
+
-
+
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
+
+
+
+
+
+
-
+
-
-
-
-
-
-
+
-
-
+
+
- Восемь сервисов с наибольшим числом связей и вызовы между ними. Стрелка идёт от вызываемого к вызывающему (serving): кого лишишься — тот и сломается. Всего в контуре 86 межсервисных связей.
+ К django обращаются 18 сервисов.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- К django обращаются 18 сервисов.
+ К documentations обращаются 11 сервисов.
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- К documentations обращаются 11 сервисов.
+ К eav обращаются 9 сервисов.
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- К eav обращаются 9 сервисов.
+ К resources обращаются 7 сервисов.
-
-
-
-
-
-
-
+
+
+
+
+
+
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- К resources обращаются 7 сервисов.
+ К processing обращаются 6 сервисов.
-
-
-
-
-
-
+
+
+
+
+
+
-
+
-
+
-
+
-
+
-
+
-
+
- К processing обращаются 6 сервисов.
+ К iam обращаются 6 сервисов.
-
-
-
-
-
-
+
+
+
+
+
+
-
+
-
+
-
+
-
+
-
+
-
+
- К iam обращаются 6 сервисов.
+ К flows обращаются 4 сервиса.
-
-
-
-
+
+
+
+
-
+
-
+
-
+
-
+
- К flows обращаются 4 сервиса.
+ К workspaces обращаются 4 сервиса.
-
-
-
-
+
+
+
+
-
+
-
+
-
+
-
+
- К workspaces обращаются 4 сервиса.
+ К system-log обращаются 3 сервиса.
-
-
-
+
+
+
-
+
-
+
-
+
- К system-log обращаются 3 сервиса.
+ К bim обращаются 3 сервиса.
-
-
-
+
+
+
-
+
-
+
-
+
- К bim обращаются 3 сервиса.
+ К pm обращаются 3 сервиса.
-
-
-
+
+
+
-
+
-
+
-
+
- К pm обращаются 3 сервиса.
-
+ Что нужно, чтобы documentations работал: 7 технологических сервисов и 15 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого documentations — представление A3.
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Что нужно, чтобы documentations работал: 7 технологических сервисов и 15 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого documentations — представление A3.
-
+ Что нужно, чтобы flows работал: 7 технологических сервисов и 8 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого flows — представление A8.
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Что нужно, чтобы flows работал: 7 технологических сервисов и 8 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого flows — представление A8.
-
+ Что нужно, чтобы issues работал: 9 технологических сервисов и 7 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у issues меньше 3, отдельного представления для них нет.
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Что нужно, чтобы issues работал: 9 технологических сервисов и 7 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у issues меньше 3, отдельного представления для них нет.
-
+ Что нужно, чтобы comparisons работал: 3 технологических сервиса и 6 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у comparisons меньше 3, отдельного представления для них нет.
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Что нужно, чтобы comparisons работал: 3 технологических сервиса и 6 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у comparisons меньше 3, отдельного представления для них нет.
-
+ Что нужно, чтобы django работал: 8 технологических сервисов и 6 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого django — представление A2.
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Что нужно, чтобы django работал: 8 технологических сервисов и 6 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого django — представление A2.
-
+ Что нужно, чтобы faas работал: 0 технологических сервисов и 5 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у faas меньше 3, отдельного представления для них нет.
+
-
+
-
+
-
+
-
+
-
+
- Что нужно, чтобы faas работал: 0 технологических сервисов и 5 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у faas меньше 3, отдельного представления для них нет.
-
+ Что нужно, чтобы transmittal работал: 6 технологических сервисов и 5 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у transmittal меньше 3, отдельного представления для них нет.
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Что нужно, чтобы transmittal работал: 6 технологических сервисов и 5 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у transmittal меньше 3, отдельного представления для них нет.
-
+ Что нужно, чтобы message-hub работал: 5 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у message-hub меньше 3, отдельного представления для них нет.
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Что нужно, чтобы message-hub работал: 5 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у message-hub меньше 3, отдельного представления для них нет.
-
+ Что нужно, чтобы pm работал: 8 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого pm — представление A12.
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Что нужно, чтобы pm работал: 8 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого pm — представление A12.
-
+ Что нужно, чтобы processing работал: 5 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого processing — представление A6.
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Что нужно, чтобы processing работал: 5 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого processing — представление A6.
-
+ Что нужно, чтобы rfi работал: 7 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у rfi меньше 3, отдельного представления для них нет.
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Что нужно, чтобы rfi работал: 7 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у rfi меньше 3, отдельного представления для них нет.
-
+ Что нужно, чтобы cde работал: 5 технологических сервисов и 3 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у cde меньше 3, отдельного представления для них нет.
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Что нужно, чтобы cde работал: 5 технологических сервисов и 3 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у cde меньше 3, отдельного представления для них нет.
-
+ Что нужно, чтобы notes работал: 6 технологических сервисов и 3 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у notes меньше 3, отдельного представления для них нет.
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
- Что нужно, чтобы notes работал: 6 технологических сервисов и 3 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у notes меньше 3, отдельного представления для них нет.
- Технологический слой типового контура. Имена кластера, узлов, доменов и реестра заменены на примеры. Прикладной слой присутствует как потребители технологических сервисов и как состав групп узлов; межсервисные связи приложений моделируются отдельно.
diff --git a/docs/architecture/example-technology.xml b/docs/architecture/example-technology.xml
index eeff0ce..7cd5623 100644
--- a/docs/architecture/example-technology.xml
+++ b/docs/architecture/example-technology.xml
@@ -3,7 +3,9 @@
xsi:schemaLocation="http://www.opengroup.org/xsd/archimate/3.0/ https://www.opengroup.org/xsd/archimate/3.1/archimate3_Diagram.xsd"
identifier="model-contour">
СДЕ Sarex — типовой контур (пример)
- Технологический слой типового контура. Имена кластера, узлов, доменов и реестра заменены на примеры. Прикладной слой присутствует как потребители технологических сервисов и как состав групп узлов; межсервисные связи приложений моделируются отдельно.
+ Архитектура типового контура платформы в двух слоях. Технологический: кластер, платформенные компоненты внутри него, внешние системы за периметром и технологические сервисы, которые всё это даёт приложениям. Прикладной: компоненты платформы по смысловым группам, вызовы между ними и зависимость каждого от технологических сервисов. Имена кластера, узлов, доменов и реестра заменены на примеры — конкретная инсталляция задаётся отдельным профилем контура.
+
+Связи не нарисованы от руки, а выведены из манифестов развёртывания: переменных окружения, аннотаций и маршрутов. Исключения оговорены отдельно — внешние интеграции и смысловая группировка приложений заданы профилем, описания компонентов получены чтением исходного кода. Как читать нотацию — представление «L1».ams-sync
@@ -1489,34 +1491,34 @@
-
-
+
+
-
+
-
+
-
+
-
+
-
+
-
+
-
-
-
-
-
+
+
+
+
+
diff --git a/docs/architecture/preview.html b/docs/architecture/preview.html
index 8905c87..1b88f12 100644
--- a/docs/architecture/preview.html
+++ b/docs/architecture/preview.html
@@ -4,19 +4,33 @@
СДЕ Sarex — типовой контур (пример)
Автогенерация из example-technology.archimate. Зелёный — технологический слой,
голубой — прикладной. Пунктир с полым треугольником — realization, стрелка — serving,
-ромб — composition, линия с шариком — assignment.
-
L1. Как читать схемы
Легенда нотации. Показан настоящий фрагмент модели, подписанный по типам: каждый элемент и каждая линия здесь встречаются на остальных представлениях в том же начертании.
T3. Внешние интеграции
Системы за периметром контура, с которыми платформа обменивается данными, и направление зависимости. Слева — технологические сервисы, которые видят приложения; справа — то, чем эти сервисы обеспечены на стороне заказчика.
Схем подключения каталога предприятия четыре, и в конкретном контуре работает одна: каталог напрямую к провайдеру идентификации платформы; каталог через брокер Keycloak; то же с доменным входом по Kerberos, который умеет проверять только брокер; либо служба федерации AD FS поверх того же каталога. Здесь показаны все четыре сразу — при развёртывании лишние узлы из профиля убираются.
T4. Потребители: Маршрутизация HTTPS-трафика
Сервисом пользуется 21 из 37 приложений контура.
T4. Потребители: Маршрутизация HTTPS-трафика
Сервисом пользуется 21 из 37 приложений контура.
T5. Потребители: Аутентификация OIDC
Сервисом пользуются 25 из 37 приложений контура.
T5. Потребители: Аутентификация OIDC
Сервисом пользуются 25 из 37 приложений контура.
T6. Потребители: Управление секретами
Сервисом пользуются 26 из 37 приложений контура.
T6. Потребители: Управление секретами
Сервисом пользуются 26 из 37 приложений контура.
T7. Потребители: Реляционное хранилище
Сервисом пользуются 24 из 37 приложений контура.
T7. Потребители: Реляционное хранилище
Сервисом пользуются 24 из 37 приложений контура.
T8. Потребители: Кэш
Сервисом пользуются 5 из 37 приложений контура.
T8. Потребители: Кэш
Сервисом пользуются 5 из 37 приложений контура.
T9. Потребители: Событийная шина
Сервисом пользуются 14 из 37 приложений контура.
T9. Потребители: Событийная шина
Сервисом пользуются 14 из 37 приложений контура.
T10. Потребители: Очередь сообщений AMQP
Сервисом пользуются 12 из 37 приложений контура.
T10. Потребители: Очередь сообщений AMQP
Сервисом пользуются 12 из 37 приложений контура.
T11. Потребители: Оркестрация процессов BPMN
Сервисом пользуется 1 из 37 приложений контура.
T11. Потребители: Оркестрация процессов BPMN
Сервисом пользуется 1 из 37 приложений контура.
T12. Потребители: Объектное хранилище
Сервисом пользуются 16 из 37 приложений контура.
T12. Потребители: Объектное хранилище
Сервисом пользуются 16 из 37 приложений контура.
T13. Потребители: Отправка почтовых уведомлений
Сервисом пользуются 6 из 37 приложений контура.
T13. Потребители: Отправка почтовых уведомлений
Сервисом пользуются 6 из 37 приложений контура.
A0. Карта прикладного слоя
Из чего состоит прикладной слой: 38 компонентов по смысловым группам. Связи здесь намеренно не показаны — на таком числе компонентов они делают схему нечитаемой; для них есть представления A1 и далее. Вложенность означает aggregation: группа объединяет компоненты, но не владеет ими.
A0. Карта прикладного слоя
Из чего состоит прикладной слой: 38 компонентов по смысловым группам. Связи здесь намеренно не показаны — на таком числе компонентов они делают схему нечитаемой; для них есть представления A1 и далее. Вложенность означает aggregation: группа объединяет компоненты, но не владеет ими.
A1. Ядро прикладного слоя
Восемь сервисов с наибольшим числом связей и вызовы между ними. Стрелка идёт от вызываемого к вызывающему (serving): кого лишишься — тот и сломается. Всего в контуре 86 межсервисных связей.
A1. Ядро прикладного слоя
Восемь сервисов с наибольшим числом связей и вызовы между ними. Стрелка идёт от вызываемого к вызывающему (serving): кого лишишься — тот и сломается. Всего в контуре 86 межсервисных связей.
A2. Зависят от: django
К django обращаются 18 сервисов.
A2. Зависят от: django
К django обращаются 18 сервисов.
A3. Зависят от: documentations
К documentations обращаются 11 сервисов.
A3. Зависят от: documentations
К documentations обращаются 11 сервисов.
A4. Зависят от: eav
К eav обращаются 9 сервисов.
A4. Зависят от: eav
К eav обращаются 9 сервисов.
A5. Зависят от: resources
К resources обращаются 7 сервисов.
A5. Зависят от: resources
К resources обращаются 7 сервисов.
A6. Зависят от: processing
К processing обращаются 6 сервисов.
A6. Зависят от: processing
К processing обращаются 6 сервисов.
A7. Зависят от: iam
К iam обращаются 6 сервисов.
A7. Зависят от: iam
К iam обращаются 6 сервисов.
A8. Зависят от: flows
К flows обращаются 4 сервиса.
A8. Зависят от: flows
К flows обращаются 4 сервиса.
A9. Зависят от: workspaces
К workspaces обращаются 4 сервиса.
A9. Зависят от: workspaces
К workspaces обращаются 4 сервиса.
A10. Зависят от: system-log
К system-log обращаются 3 сервиса.
A10. Зависят от: system-log
К system-log обращаются 3 сервиса.
A11. Зависят от: bim
К bim обращаются 3 сервиса.
A11. Зависят от: bim
К bim обращаются 3 сервиса.
A12. Зависят от: pm
К pm обращаются 3 сервиса.
A12. Зависят от: pm
К pm обращаются 3 сервиса.
P1. Паспорт: documentations
Что нужно, чтобы documentations работал: 7 технологических сервисов и 15 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого documentations — представление A3.
P1. Паспорт: documentations
Что нужно, чтобы documentations работал: 7 технологических сервисов и 15 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого documentations — представление A3.
P2. Паспорт: flows
Что нужно, чтобы flows работал: 7 технологических сервисов и 8 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого flows — представление A8.
P2. Паспорт: flows
Что нужно, чтобы flows работал: 7 технологических сервисов и 8 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого flows — представление A8.
P3. Паспорт: issues
Что нужно, чтобы issues работал: 9 технологических сервисов и 7 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у issues меньше 3, отдельного представления для них нет.
P3. Паспорт: issues
Что нужно, чтобы issues работал: 9 технологических сервисов и 7 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у issues меньше 3, отдельного представления для них нет.
P4. Паспорт: comparisons
Что нужно, чтобы comparisons работал: 3 технологических сервиса и 6 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у comparisons меньше 3, отдельного представления для них нет.
P4. Паспорт: comparisons
Что нужно, чтобы comparisons работал: 3 технологических сервиса и 6 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у comparisons меньше 3, отдельного представления для них нет.
P5. Паспорт: django
Что нужно, чтобы django работал: 8 технологических сервисов и 6 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого django — представление A2.
P5. Паспорт: django
Что нужно, чтобы django работал: 8 технологических сервисов и 6 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого django — представление A2.
P6. Паспорт: faas
Что нужно, чтобы faas работал: 0 технологических сервисов и 5 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у faas меньше 3, отдельного представления для них нет.
P6. Паспорт: faas
Что нужно, чтобы faas работал: 0 технологических сервисов и 5 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у faas меньше 3, отдельного представления для них нет.
P7. Паспорт: transmittal
Что нужно, чтобы transmittal работал: 6 технологических сервисов и 5 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у transmittal меньше 3, отдельного представления для них нет.
P7. Паспорт: transmittal
Что нужно, чтобы transmittal работал: 6 технологических сервисов и 5 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у transmittal меньше 3, отдельного представления для них нет.
P8. Паспорт: message-hub
Что нужно, чтобы message-hub работал: 5 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у message-hub меньше 3, отдельного представления для них нет.
P8. Паспорт: message-hub
Что нужно, чтобы message-hub работал: 5 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у message-hub меньше 3, отдельного представления для них нет.
P9. Паспорт: pm
Что нужно, чтобы pm работал: 8 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого pm — представление A12.
P9. Паспорт: pm
Что нужно, чтобы pm работал: 8 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого pm — представление A12.
P10. Паспорт: processing
Что нужно, чтобы processing работал: 5 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого processing — представление A6.
P10. Паспорт: processing
Что нужно, чтобы processing работал: 5 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого processing — представление A6.
P11. Паспорт: rfi
Что нужно, чтобы rfi работал: 7 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у rfi меньше 3, отдельного представления для них нет.
P11. Паспорт: rfi
Что нужно, чтобы rfi работал: 7 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у rfi меньше 3, отдельного представления для них нет.
P12. Паспорт: cde
Что нужно, чтобы cde работал: 5 технологических сервисов и 3 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у cde меньше 3, отдельного представления для них нет.
P12. Паспорт: cde
Что нужно, чтобы cde работал: 5 технологических сервисов и 3 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у cde меньше 3, отдельного представления для них нет.
P13. Паспорт: notes
Что нужно, чтобы notes работал: 6 технологических сервисов и 3 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у notes меньше 3, отдельного представления для них нет.
P13. Паспорт: notes
Что нужно, чтобы notes работал: 6 технологических сервисов и 3 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у notes меньше 3, отдельного представления для них нет.
+Заметки и примечания на объектах проекта: пометка на 2D-чертеже или в 3D-модели со сроком, цветом, фотографиями, вложениями и связями с сущностями разных сервисов. Поддерживает отправку скриншота вида и формирование документа по заметке;notesПроверка личности пользователя и выдача токена, по которому сервисы принимают решение о доступе. Самый массово используемый сервис контура.Аутентификация OIDCВыдача приложениям реквизитов доступа к базам, брокерам и хранилищам во время запуска пода. Практически универсальная зависимость: почти каждый сервис с состоянием стартует только после успешного получения секретов, поэтому недоступность этого сервиса останавл…Управление секретамиХранение структурированных данных доменных областей: карточек, связей, статусов, журналов. У каждого сервиса своя база, общей схемы нет — обмен между сервисами идёт через API и шины, а не через общие таблицы.Реляционное хранилищеАсинхронная публикация событий с сохранением журнала и несколькими независимыми потребителями. Используется там, где важен факт изменения и возможность его повторно прочитать: аудит, уведомления, синхронизация состояний между доменами.Событийная шинаАдресная доставка задач фоновым обработчикам с подтверждением и повторами. Обслуживает длительные операции — конвертацию, выгрузки, рассылки, — которые нельзя выполнять внутри HTTP-запроса.Очередь сообщений AMQPХранение и выдача файлов: документов, чертежей, моделей, вложений и производных представлений. Базовый сервис для всех документоориентированных областей платформы — в реляционных базах лежат только метаданные, содержимое всегда здесь.Объектное хранилищеУниверсальное хранилище файловых вложений к любым сущностям платформы: файл кладётся в S3, метаданные — в PostgreSQL, привязка полиморфная («имя модели + идентификатор экземпляра»).attachmentsЛегаси-монолит и ядро продукта: компании, пользователи, роли и подрядчики, объекты строительства, миссии аэрофотосъёмки, ортофотопланы, облака точек и поверхности, измерения, аналитика с дашбордами и метриками, карта, ТОиР, уведомления и журнал действий.djangoРабочая среда документации проекта: диски, дерево папок, документы с версиями, страницами, атрибутами, правами и связями; штампы, ЭЦП, подписки, корзина, публичные ссылки. Отвечает также за постановку загруженных инженерных форматов в очередь конвертации.documentations
+
Прикладной слой: описания компонентов
38 компонентов в том же порядке, что и на карте A0. Описания выведены не из манифестов контура, а из исходного кода компонентных репозиториев, и потому проверяются чтением кода, а не сверкой с конфигурацией. То же описание всплывает подсказкой, если задержать курсор на блоке любой схемы.
Платформа
Общие механизмы, на которые опираются все прикладные домены: единая точка входа в интерфейс, вход и права, справочник атрибутов, рабочие пространства и проекты как контейнеры данных, журнал действий, уведомления, оркестрация процессов.
Почти все связи прикладного слоя ведут сюда, поэтому изменения в этой группе стоят дороже всего: отказ любого её компонента виден сразу во всех доменах, тогда как отказ прикладного сервиса ограничен своей областью.
ams-sync
Односторонняя синхронизация учётных записей из ядра платформы во внешний провайдер идентификации: созданный или изменённый пользователь вместе с профилем, принадлежностью организации и метаданными появляется в Zitadel, где на этих данных строится авторизация доменных сервисов. Работает консьюмером Kafka-топика, отдельный консольный режим использовался для первичной массовой миграции пользователей и компаний. Входящих вызовов не принимает.
Административный контур платформы (srx-admin): управление пользователями, ролями, атрибутами, подразделениями, проектами и функциональными группами, а также реестром активов компании с правами доступа. Отдельный крупный сценарий — пакетный импорт активов из XLSX со статусами заданий и отчётами об ошибках.
Стек: TypeScript · React · MobX · Material-UI и ui-kit · Webpack 5 Module Federation · монорепозиторий npm-workspaces; собственного хранилища нет.
django
Легаси-монолит и ядро продукта: компании, пользователи, роли и подрядчики, объекты строительства, миссии аэрофотосъёмки, ортофотопланы, облака точек и поверхности, измерения, аналитика с дашбордами и метриками, карта, ТОиР, уведомления и журнал действий. Здесь же — основной SPA-хост, в который встраиваются все микрофронтенды платформы.
Универсальная модель «сущность — атрибут — значение»: пользовательские атрибуты, их типы, схемы и справочники, расширяющие любые доменные объекты без изменения схемы БД. Второй блок — иерархический классификатор активов объекта (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 и умеет автоматически инициировать трансмиттал после завершения маршрута.
Платформенный 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-сервисов документации.
Публичная страница выданной наружу ссылки на документ: получатель без учётной записи видит карточку документа и скачивает файл. Собственного бэкенда нет — данные отдаёт публичный эндпоинт 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
Формальные запросы информации между участниками проекта: запрос с приоритетом, статусом, ответственными и привязкой к ресурсу, переписка сообщениями с пометкой одного из них как решения. Приоритеты и статусы настраиваются на уровне компании, ведётся полный журнал изменений полей.
Данные, приходящие со стройплощадки: замеры, привязка к местности, сечения, а также обработка тяжёлых входных файлов.
Единственная группа с существенной вычислительной нагрузкой: обработка вынесена на отдельные узлы, потому что её всплески не должны мешать интерактивной работе остальных сервисов.
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.