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

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

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

Стек: Python · FastAPI · PostgreSQL (psycopg2, сырой SQL; Alembic только для схемы) · S3 через boto3 · OpenTelemetry.
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 в инфраструктуре.
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.
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).
contracts
Реестр договоров компании: номер, подрядчик, сроки, стоимость, привязка к проекту или объекту. Даёт коммерческий контур поверх производственных данных; на договор, в частности, ссылается предписание.

Стек: Go · Fiber v3 · pgx + squirrel · PostgreSQL (JSONB) · фронтенд на TypeScript/React/MobX по Feature-Sliced Design.
control-interface
Административный контур платформы (srx-admin): управление пользователями, ролями, атрибутами, подразделениями, проектами и функциональными группами, а также реестром активов компании с правами доступа. Отдельный крупный сценарий — пакетный импорт активов из XLSX со статусами заданий и отчётами об ошибках.

Стек: TypeScript · React · MobX · Material-UI и ui-kit · Webpack 5 Module Federation · монорепозиторий npm-workspaces; собственного хранилища нет.
cross-section
Инструмент построения поперечных сечений по облакам точек и BIM-документам прямо во вьюере, с сохранением сечений, цветовой легендой документов и экспортом в DWG. Применяется при обмере и контроле построенного; серверная часть — drawings.

Стек: TypeScript · React · MobX · pixi-viewer · джоб экспорта в DWG на Go с Python-генератором · PostgreSQL · объектное хранилище.
django
Легаси-монолит и ядро продукта: компании, пользователи, роли и подрядчики, объекты строительства, миссии аэрофотосъёмки, ортофотопланы, облака точек и поверхности, измерения, аналитика с дашбордами и метриками, карта, ТОиР, уведомления и журнал действий. Здесь же — основной SPA-хост, в который встраиваются все микрофронтенды платформы.

Стек: Python · Django + DRF · django-guardian · channels · Celery + Redis · Kafka · PostgreSQL, ClickHouse, MongoDB, S3 · фронтенд на TypeScript/React/MobX (Module Federation, PWA).
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.
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.
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.
mapper
Агрегирующий сервис (BFF), склеивающий данные нескольких API в один ответ для интерфейса: реестр документов диска вместе с состоянием согласования и заметки вместе с их связями. Собственной доменной модели и базы не имеет, ответы кеширует в Redis.

Стек: Python · FastAPI · httpx с ретраями · Redis/RedisJSON как кеш; собственной БД нет.
measurements
Геопространственные измерения по материалам аэросъёмки: высота и температура в точке, профиль вдоль ломаной, расчёт объёма по контуру и разности объёмов между съёмками, метаданные растров и пересчёт координат. Stateless-сервис без собственной БД, читающий GeoTIFF напрямую из объектного хранилища.

Стек: Python · FastAPI · GDAL, pyproj, NumPy, OpenCV, SciPy · чтение GeoTIFF из S3 через boto3; собственной БД нет.
message-hub
Событийный хаб домена планирования: принимает события Kafka и выполняет побочные действия — пересчёт аналитики, обновление атрибутов, письма, экспорты, системный журнал, автопланирование, синхронизацию проектов и ресурсов. Транслирует изменения в браузер по WebSocket, обеспечивая живое обновление доски проекта.

Стек: Python · FastStream + Kafka (aiokafka) · python-socketio с Redis · SQLAlchemy Core с сырым SQL к PostgreSQL · S3 · Jinja2 для писем.
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.
prescriptions
Выдача предписаний подрядчику по результатам строительного контроля: предписание собирается из замечаний, привязывается к договору, подрядчику и объекту, получает номер и проходит согласование по статусам. Официальный документ формируется по шаблону движком workflow; бэкенд — приложение внутри issues.

Стек: Python · Django + DRF · PostgreSQL (приложение внутри бэкенда issues) · генерация документов движком workflow · фронтенд на React/MobX (rsbuild + Module Federation).
processing
Фабрика тяжёлых вычислений платформы: движок workflow исполняет граф задач, каждая из которых запускается отдельным контейнером (Kubernetes Job или воркер через RabbitMQ). Через него работают конвертация форматов, сравнения, экспорт в DWG и генерация документов; отдельный интерфейс даёт мониторинг, логи, отмену и перезапуск задач.

Стек: Go (pgx, go-pg, zap) · PostgreSQL · Kubernetes client-go для джобов · RabbitMQ для сторонних воркеров · джобы на Python (boto3, внутренняя workflows-tools) · фронтенд на React/MobX.
projects
Витрина проектов и карточка проекта — верхнеуровневый вход пользователя в платформу: атрибуты, местоположение, фотографии, группировки и настраиваемые вкладки с разделами-виджетами. Агрегирует показатели остальных модулей, включая встраивание внешней аналитики.

Стек: Python · FastAPI · async SQLAlchemy 2.0 + Alembic · PostgreSQL (JSONB) · S3 · фронтенд на React/MobX с TanStack Query и leaflet · встраивание Superset.
remarks
Пользовательский модуль работы с замечаниями (UI): пин на чертеже, в ячейке XLSX или на задаче графика, описание, срок, ответственные, вложения и пометки поверх листа, табличное и списочное представления, фильтры, массовое редактирование и экспорт. Собственный бэкенд архивирован — модуль работает поверх issues.

Стек: TypeScript · React · MobX · Material-UI · TanStack Table и Virtual; серверная часть — стек issues.
resources
Единый реестр ресурсов платформы — иерархия объектов строительства (проект, объект, участок и ниже) с типами, географическим положением, кодами и правами доступа. Идентификатор ресурса служит сквозным ключом проекта во всех остальных сервисах, а сам реестр — общей точкой проверки прав, поэтому это один из самых востребованных компонентов контура. Интеграция только синхронная, по HTTP.

Стек: Python · Django + DRF · django-filter · PostgreSQL с ltree и PostGIS · фронтенд в отдельном репозитории.
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).
stamp-verification
Публичная страница проверки подлинности документа по QR-штампу: сканирование кода с бумажной или PDF-копии открывает карточку с документом, страницей и его актуальным состоянием, включая статус согласования. Авторизация не требуется; серверная часть — публичный эндпоинт documentations.

Стек: Статический сайт без сборщика: HTML, vanilla JS, moment.js; серверная часть — Go (gorilla/mux, go-pg, PostgreSQL) в составе documentation-api.
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.
transmittal
Формальная передача комплектов документации между участниками — сопроводительное письмо с составом, получателями, сроком и результатом приёма или отклонения. По завершении формируется акт передачи в PDF; есть шаблоны трансмитталов и связь с согласованиями, замыкающая цикл «выдал документацию → получил замечания».

Стек: Python · FastAPI · async SQLAlchemy + Alembic · PostgreSQL · S3 · taskiq + RabbitMQ · Jinja2 с собственным конвертером HTML в PDF · Mailgun и SMTP · фронтенд на React/MobX (Module Federation).
workspaces
Рабочее пространство — сцена, в которой пользователь одновременно работает с BIM-моделями, облаками точек, PDF-чертежами и панорамами объекта, настраивает отображение и сохраняет именованные состояния. Поддерживает установку прикладных модулей компании как федеративных приложений внутри сцены и архивирование данных при закрытии этапов.

Стек: Go (gorilla/mux, go-pg, Prometheus, Sentry, JWT на RSA) · PostgreSQL · фронтенд на TypeScript/React/MobX с viewer (Module Federation), кеш в IndexedDB · тесты Cypress и Jest.
Конвертер 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 свойств.
Кластер k8s-prod
Flux CD — набор контроллеров Kubernetes, реализующий подход GitOps: вся система описана декларативно и находится под контролем версий, а автоматика непрерывно приводит развёрнутое окружение в соответствие состоянию, заданному в Git. Контроллеры с заданным интервалом сравнивают фактическое состояние ресурсов с желаемым и применяют расхождения. Основные ресурсы: GitRepository описывает источник, Kustomization — набор манифестов для согласования, HelmRelease — развёртывание Helm-чарта.

Кластер Kubernetes, в котором работает вся платформа. Состав задаётся одним файлом clusters/<контур>/kustomization.yaml — плоским списком инфраструктурных компонентов и приложений; он же является источником истины о том, что развёрнуто. Доставка изменений — GitOps через FluxCD v2: Flux читает манифесты из Git-сервера контура и приводит кластер к описанному состоянию, ручной kubectl apply в нормальном процессе не используется. Прикладные сервисы ставятся не собственными чартами, а одним общим universal-chart, что делает их конфигурацию единообразной.
Istio Ingress Gateway
Istio — открытый service mesh, который прозрачно накладывается на существующие распределённые приложения и централизованно управляет взаимодействием сервисов, не требуя изменений в коде. Ingress-шлюз — это компонент плоскости данных Istio на границе mesh: он принимает внешний трафик, терминирует TLS и передаёт запросы внутрь по правилам, заданным ресурсами Gateway и VirtualService.

Единственная точка входа внешнего трафика в контур. Терминирует TLS и передаёт запросы дальше по правилам service mesh. Публикуется через NodePort и в типовой конфигурации привязан к выделенному узлу — это делает его единственной точкой отказа для всего внешнего доступа: при потере узла контур остаётся живым внутри, но недоступен снаружи. Резервирование ingress стоит рассматривать отдельно от резервирования приложений.
Istio Service Mesh
Istio разделён на плоскость управления, которая хранит конфигурацию и раздаёт её прокси, и плоскость данных из прокси Envoy рядом с каждым подом. Такая схема даёт три группы возможностей: управление трафиком (маршрутизация, балансировка HTTP/gRPC/TCP, повторы и переключение при отказах), безопасность (взаимный TLS между сервисами) и наблюдаемость — метрики, логи и трассировки для всего трафика кластера собираются автоматически. Конфигурация меняется на лету: Istio перепрограммирует прокси без пересборки и перезапуска приложений.

Управляющая конфигурация сети: Gateway описывает внешние точки входа, VirtualService — маршрутизацию по путям на конкретные сервисы, RequestAuthentication — проверку JWT на входе. Поставляется чартом istio-config-contour и является тем местом, где видно, какие приложения вообще опубликованы наружу. В части контуров разводка по путям вынесена за пределы репозитория во внешний nginx — тогда в модели виден только факт публикации, но не таблица маршрутов. Sidecar-прокси рядом с каждым подом дают mTLS между сервисами и метрики трафика.
cert-manager
cert-manager — расширение Kubernetes, которое выпускает TLS-сертификаты для нагрузок в кластере и продлевает их до истечения срока. Ресурсы Issuer и ClusterIssuer описывают, у какого удостоверяющего центра и на каких условиях получать сертификат, а ресурс Certificate — сам запрошенный сертификат; результат складывается в секрет Kubernetes, откуда его читают поды и ingress-контроллеры. Поддерживаются разные источники: Let's Encrypt, HashiCorp Vault, внутренние PKI и самоподписанные издатели.

Выпускает и автоматически продлевает TLS-сертификаты для внешних доменов контура. Работает через ClusterIssuer: в контурах с доступом в интернет это Let's Encrypt, в закрытых — самоподписанный издатель, как в этом примере. Выпущенный wildcard-сертификат складывается в секрет, который использует ingress-gateway. Практическое следствие самоподписанного варианта: клиентам нужно доверять корневому сертификату контура, иначе браузеры и интеграции будут ругаться.
Zitadel
Zitadel — платформа управления идентификацией, реализующая отраслевые стандарты OIDC, OAuth 2.0 и SAML для входа и единой аутентификации. Отличительные черты — мультиарендность с настройкой оформления под каждого арендатора, полный журнал аудита на основе event sourcing и возможность развёртывания как в облаке, так и на своих мощностях. Закрывает задачи аутентификации, многофакторной проверки и управления пользователями без разработки собственной подсистемы входа.

Основной поставщик идентичности платформы, отвечает за аутентификацию пользователей по OIDC и выдачу токенов. Прикладные сервисы не проверяют пароли сами: они валидируют JWT по публичному ключу, а на границе контура это же делает Istio через RequestAuthentication. Самый широко используемый технологический сервис контура — с ним так или иначе работает подавляющее большинство приложений, включая фронтенды. Отдельный микрофронтенд auth-flow обслуживает сценарий логина и обработку OIDC-callback. Keycloak в платформе тоже встречается, но как вторичный вариант и внутри поставки Camunda.
Vault + Agent Injector
HashiCorp Vault — централизованная система управления секретами: учётными данными, ключами шифрования и сертификатами, с аудитом всех обращений. Работает по схеме «клиент аутентифицируется — получает токен, связанный с набором политик — обращается к секретам по путям — Vault проверяет права и записывает обращение в журнал независимо от исхода». Модульная архитектура позволяет подключать разные способы аутентификации и разные хранилища секретов, включая выдачу временных учётных данных к базам данных.

Единственный механизм доставки секретов приложениям. Секреты не лежат в манифестах и не хранятся в Git: под получает их через sidecar Agent Injector, который аутентифицируется в Vault по service account пода и монтирует значения из пути вида secrets/data/apps/<приложение>/postgres. Ролью и service account служит имя приложения — соглашение единообразно для всех сервисов. Трафик к Vault выведен из-под sidecar-прокси Istio отдельной аннотацией, иначе инициализация пода не проходит.
PostgreSQL
PostgreSQL — объектно-реляционная СУБД с открытым исходным кодом и почти сорокалетней историей развития. Соответствует требованиям ACID, использует многоверсионное управление конкурентным доступом (MVCC) и покрывает не менее 170 из 177 обязательных возможностей ядра стандарта SQL:2023. Поддерживает широкий набор типов данных, включая JSON и JSONB, геометрические и пользовательские типы, а также расширения — хранимые процедуры на нескольких языках, обёртки сторонних источников данных и геопространственное расширение PostGIS.

Основное реляционное хранилище контура и самый востребованный технологический сервис после управления секретами. Разворачивается внутри кластера как StatefulSet на сетевом хранилище; в части контуров вместо него используется внешняя managed-СУБД, и тогда в кластере остаются только реквизиты подключения. Базы разделены по приложениям — общей схемы нет, каждый сервис владеет своими таблицами, что важно для независимости релизов. Реквизиты всегда приходят через Vault, поэтому в манифестах приложения видна лишь аннотация инжектора.
Redis
Redis — сервер структур данных, хранящий данные в оперативной памяти. Помимо строк поддерживает хеши, списки, множества, упорядоченные множества и потоки — журнал с добавлением в конец. Такой набор примитивов закрывает разные задачи одним инструментом: кэширование, хранение сессий, очереди, счётчики и обработку событий. Предусмотрены механизмы сохранения данных на диск, что позволяет пережить перезапуск.

Кэш и брокер фоновых задач. В отличие от PostgreSQL, не является общей инфраструктурой контура: разворачивается точечно, в namespace тех приложений, которым он действительно нужен — как правило, там, где есть Celery-воркеры или требуется разделяемое состояние между репликами. Из-за этого экземпляров Redis в контуре несколько и они независимы; общего кэша, через который сервисы обмениваются данными, в платформе нет.
Kafka
Apache Kafka — платформа потоковой обработки событий: публикация, хранение и обработка непрерывных потоков данных в реальном времени. События пишутся в темы, темы делятся на разделы и распределяются по брокерам ради масштабирования; производители пишут, потребители читают. Ключевое отличие от обычной очереди в том, что событие не удаляется после прочтения, а хранится по настраиваемой политике — поэтому его можно перечитать заново и подключить новых потребителей к уже накопленной истории.

Шина событий для асинхронного обмена между сервисами. Используется там, где нужен журнал событий с возможностью повторного чтения и несколькими независимыми потребителями: аудит действий, уведомления, синхронизация состояний между доменами. Соседствует с RabbitMQ, и это осознанное разделение, а не дублирование: Kafka отвечает за поток событий, RabbitMQ — за адресную доставку задач. Часть приложений подключена к обеим шинам одновременно.
RabbitMQ
RabbitMQ — брокер сообщений, реализующий протокол AMQP 0-9-1 для асинхронного обмена между приложениями. Опубликованное сообщение попадает в обменник, привязки маршрутизируют его в очереди по ключу маршрутизации, а из очередей его забирают потребители. Доставка подтверждается: при явном подтверждении потребитель сообщает об успешной обработке, и если он отвалился, не подтвердив сообщение, брокер передаст его другому потребителю или дождётся появления нового — сообщение не теряется.

Очередь задач для фоновой обработки: выгрузки, конвертация документов, рассылки, длительные операции, которые нельзя выполнять в HTTP-запросе. В отличие от Kafka, ориентирован на адресную доставку конкретному обработчику с подтверждением и повторами. В ряде контуров панель управления публикуется наружу отдельным доменом, что удобно для эксплуатации, но требует внимания к доступу — это полноценный административный интерфейс.
Camunda Platform
Camunda 8 — платформа оркестрации и автоматизации бизнес-процессов с участием людей, систем и устройств. В её основе движок Zeebe, координирующий исполнение процессов в распределённой среде; Operate и Tasklist дают операционную видимость и работу с пользовательскими задачами, Optimize — аналитику по исполнению. Работу выполняют job-воркеры: внешние компоненты, которые опрашивают кластер на предмет заданий своего типа, обрабатывают их и возвращают результат.

Движок исполнения бизнес-процессов в нотации BPMN. Через него проходят маршруты согласования документов: процесс описывает шаги и условия, а конкретные действия выполняют воркеры прикладных сервисов, подключённые к Zeebe как job-workers по типу задачи. Это единственный компонент контура, где логика согласования выражена декларативно и её можно менять без пересборки сервисов. Важная особенность для чтения конфигурации: переменные ZEEBE_* и CAMUNDA_* приходят из k8s-секрета, поэтому в манифестах приложений связь с Camunda не видна — она подтверждается только документацией сервисов.
Zeebe
Ядро движка: хранит состояние запущенных процессов и раздаёт задачи воркерам. Работает как StatefulSet, состояние на диске.
Zeebe Gateway
Точка подключения клиентов и job-workers к ядру. Именно её адрес прикладные сервисы получают в переменной ZEEBE_GATEWAY.
Operate
Интерфейс и REST API для наблюдения за экземплярами процессов: где застрял маршрут, какие переменные, какие инциденты. Используется не только людьми — прикладные сервисы обращаются к его API программно.
Tasklist
Интерфейс пользовательских задач BPMN — шагов процесса, требующих действия человека.
Optimize
Аналитика по исполнению процессов: длительности, узкие места, статистика прохождения маршрутов.
Identity
Управление доступом к компонентам Camunda и выдача OAuth-токенов для машинного доступа. В поставке идёт вместе с собственным Keycloak, отдельным от основного поставщика идентичности контура.
Connectors
Готовые коннекторы к внешним системам, вызываемые из процесса без написания своего воркера.
s3.example.com — объектное хранилище
Объектное хранилище — масштабируемый репозиторий для неструктурированных данных: файлов, медиа, журналов и резервных копий, без ограничений традиционной файловой системы. Отраслевым стандартом доступа стал API S3, поэтому такие хранилища взаимозаменяемы для приложения. В self-hosted варианте обычно применяется MinIO с S3-совместимым API и распределённым развёртыванием на основе избыточного кодирования (erasure coding): данные разрезаются на фрагменты с избыточностью и раскладываются по узлам, что позволяет пережить отказ части из них дешевле, чем при простом дублировании.

Хранилище файлов платформы: документы, чертежи, модели, вложения, результаты конвертации. Вынесено за пределы кластера — в одних контурах это MinIO на отдельных узлах, в других внешний S3-совместимый сервис заказчика. Именно здесь лежит основной объём данных: базы хранят метаданные и связи, а сами файлы всегда в объектном хранилище. Прямой доступ браузера к хранилищу не используется, отдача файлов идёт через прокси-сервис платформы.
Сетевое хранилище (StorageClass)
Класс хранения, из которого выделяются тома для компонентов с состоянием — прежде всего для PostgreSQL, а также для брокеров и движка процессов. От его производительности напрямую зависит отзывчивость СУБД, поэтому это место стоит проверять первым при жалобах на медленную работу платформы.
Git-сервер контура
Хранит манифесты, из которых Flux собирает состояние кластера. В закрытых контурах наполняется зеркалированием из основного репозитория разработки, что даёт контуру автономность: даже при отсутствии связи с внешним миром развёртывание работает из локальной копии. Практически это означает, что изменение, попавшее в основной репозиторий, доедет до контура не мгновенно, а после синхронизации зеркала.
registry.example.com
Реестр, из которого кластер получает и Helm-чарты (в формате OCI), и образы контейнеров. Единая точка поставки: версия чарта и тег образа, указанные в манифестах, разрешаются именно здесь. Доступность реестра — обязательное условие для развёртывания и перезапуска подов, поэтому в закрытых контурах он размещается внутри периметра.
Helm-чарты (OCI)
Образы контейнеров
smtp.example.com — почтовый релей
SMTP — протокол передачи почты. Релей заказчика принимает исходящие сообщения от приложений контура и доставляет их адресатам; приложение аутентифицируется логином и паролем сервисной учётной записи, транспорт защищается TLS — либо сразу (порт 465), либо через STARTTLS (порт 587).

Единственный канал, которым платформа по своей инициативе выходит за периметр: уведомления о назначенных задачах, замечаниях, запросах и отправленных трансмитталах. Адрес релея, порт и учётные данные задаются переменными окружения приложений. Отказ релея не останавливает работу платформы — перестают доходить только письма, и это стоит проверять первым при жалобах «уведомления не приходят».
Keycloak — брокер идентификации
Keycloak — открытый сервер управления доступом: поддерживает OIDC, OAuth 2.0 и SAML, умеет подтягивать пользователей из LDAP и Active Directory и принимать доменный вход по Kerberos (механизм SPNEGO). В схеме интеграции работает брокером: для платформы это обычный OIDC-провайдер, а в сторону предприятия — клиент корпоративного каталога.

Появляется в контуре там, где провайдер идентификации платформы не может обратиться к каталогу заказчика напрямую: нужен прозрачный доменный вход, источников пользователей несколько или каталог опубликован по SAML. Платформа поставляет чарт keycloak-contour, поэтому брокер может стоять как на стороне заказчика, так и внутри контура. Цена варианта — лишнее звено в цепочке входа: при недоступности брокера вход невозможен, даже если каталог и провайдер идентификации работают.
AD FS — служба федерации
Active Directory Federation Services — служба федерации Microsoft поверх домена Active Directory. Выдаёт токены по SAML 2.0, WS-Federation и OIDC, а проверку самих учётных данных оставляет домену.

Альтернатива брокеру в тех контурах, где федеративная служба у заказчика уже развёрнута и является штатной точкой входа для корпоративных систем. Для платформы подключается как внешний провайдер идентификации: собственных учётных записей платформа при этом не заводит, а получает утверждения о пользователе от службы федерации.
Active Directory — каталог предприятия
Active Directory — служба каталогов Microsoft: хранит учётные записи, группы и организационную структуру предприятия и отвечает на запросы по LDAP (порт 389) и LDAPS (порт 636). Для предприятия это источник истины о сотрудниках.

Каталог заказчика — то, откуда пользователи попадают в платформу. Схем подключения четыре: напрямую к провайдеру идентификации платформы по LDAPS; через брокер Keycloak; через брокер с доменным входом по Kerberos; через службу федерации AD FS. Выбор делается при развёртывании и определяет, какие из внешних узлов этой группы вообще появятся в контуре. Общее у всех четырёх одно: учётные записи платформа не заводит, а получает, поэтому отключение сотрудника в каталоге закрывает ему и доступ в платформу.
Kerberos KDC — центр выдачи билетов
Kerberos — протокол сетевой аутентификации на билетах, встроенный в домен Active Directory. Центр выдачи билетов работает на контроллерах домена и слушает порт 88 по TCP и UDP.

Нужен только ради прозрачного входа: пользователь, уже вошедший в домен на рабочей станции, попадает в платформу без повторного ввода пароля. Билет проверяет брокер по механизму SPNEGO, поэтому сценарий с Kerberos всегда предполагает брокер в цепочке. Работает лишь для рабочих станций внутри домена — внешние подрядчики в этом же контуре входят обычным паролем.
frontend-node-01
Узел, к которому привязан ingress-gateway через nodeSelector. Привязка сделана ради предсказуемого адреса для внешней балансировки и правил межсетевого экрана, но ценой того, что внешний доступ зависит от одного узла.
Маршрутизация HTTPS-трафика
Публикация приложений наружу: терминация TLS, разбор внешнего домена и пути, направление запроса нужному сервису, проверка токена на границе. Сервисом пользуются только те приложения, у которых есть внешний интерфейс; остальные доступны исключительно внутри кластера.
Выпуск TLS-сертификатов
Автоматическое получение и продление сертификатов для доменов контура. Потребитель у сервиса один — ingress-gateway; приложения с ним не взаимодействуют, поэтому отдельного представления с потребителями у него нет.
Аутентификация OIDC
Проверка личности пользователя и выдача токена, по которому сервисы принимают решение о доступе. Самый массово используемый сервис контура. Значительная часть связей подтверждается только документацией приложений: публичный ключ и параметры подключения приходят из секретов, а не из манифестов.
Управление секретами
Выдача приложениям реквизитов доступа к базам, брокерам и хранилищам во время запуска пода. Практически универсальная зависимость: почти каждый сервис с состоянием стартует только после успешного получения секретов, поэтому недоступность этого сервиса останавливает не работу, а перезапуск и выкатку.
Реляционное хранилище
Хранение структурированных данных доменных областей: карточек, связей, статусов, журналов. У каждого сервиса своя база, общей схемы нет — обмен между сервисами идёт через API и шины, а не через общие таблицы.
Кэш
Разделяемое короткоживущее состояние и очередь фоновых задач для сервисов с Celery-воркерами. Востребован узким кругом приложений, поэтому разворачивается точечно, а не как общая инфраструктура контура.
Событийная шина
Асинхронная публикация событий с сохранением журнала и несколькими независимыми потребителями. Используется там, где важен факт изменения и возможность его повторно прочитать: аудит, уведомления, синхронизация состояний между доменами.
Очередь сообщений AMQP
Адресная доставка задач фоновым обработчикам с подтверждением и повторами. Обслуживает длительные операции — конвертацию, выгрузки, рассылки, — которые нельзя выполнять внутри HTTP-запроса.
Оркестрация процессов BPMN
Исполнение маршрутов согласования, описанных схемой BPMN: движок ведёт состояние процесса и раздаёт шаги воркерам прикладных сервисов. Позволяет менять логику согласования без пересборки сервисов. Связь с потребителем не видна в манифестах — параметры подключения приходят из секрета.
Объектное хранилище
Хранение и выдача файлов: документов, чертежей, моделей, вложений и производных представлений. Базовый сервис для всех документоориентированных областей платформы — в реляционных базах лежат только метаданные, содержимое всегда здесь.
Отправка почтовых уведомлений
Отправка исходящей почты приложениями контура. Собственного почтового сервера платформа не содержит — сервис реализуется релеем заказчика. Через него уходят уведомления о назначенных задачах, замечаниях, запросах и отправленных трансмитталах.
Группа узлов processing (Сервера приложений)
Узлы под вычислительно тяжёлую обработку, вынесенную из общего пула приложений: конвертация и разбор файлов, построение производных представлений документов и моделей. Отделены от остальных прикладных серверов намеренно — такая нагрузка неравномерна и способна вытеснить интерактивные сервисы, если делить с ними ресурсы.
Группа узлов generic (Сервера приложений)
Основной пул прикладных серверов: здесь работает подавляющее большинство сервисов платформы — и бэкенды доменных областей, и микрофронтенды. Нагрузка преимущественно интерактивная, запрос-ответ. Это самая массовая группа, и именно её объём определяет, сколько ресурсов требует контур.
Объектное хранилище
Узлы файлового хранилища. Отделены от вычислительных, потому что растут по другому закону: объём здесь определяется накопленными документами и моделями за всё время эксплуатации, а не числом одновременных пользователей. Это же делает группу главным кандидатом на резервное копирование.
Группа узлов DB (Базы данных)
Узлы СУБД. Вынесены отдельно по двум причинам: предсказуемая производительность дисков и возможность обслуживать базы, не затрагивая прикладные сервисы. Хранят метаданные и связи всех доменных областей; при потере данных этой группы файлы в объектном хранилище останутся, но станут неадресуемыми.
Группа узлов K8s (Поддерживающая инфраструктура)
Узлы платформенных сервисов, на которых не работает прикладная логика: сеть и вход в контур, идентификация, секреты, брокеры, движок процессов, кэш. Прикладные сервисы без этой группы нефункциональны — здесь сосредоточены зависимости, общие для всех доменных областей.
Репозиторий компонентов
Узлы поставки: реестр чартов и образов, а также Git-сервер, из которого Flux читает манифесты. Обеспечивают автономность контура — развёртывание и перезапуск не требуют выхода во внешнюю сеть. Состав группы требует подтверждения: не исключено, что под репозиторием компонентов понимается только реестр артефактов.
CAD ферма
Узлы обработки исходных файлов BIM-моделей в проприетарных форматах NWD и RVT. Работают асинхронно: воркер разбирает очередь заданий, забирает исходный файл из объектного хранилища, конвертирует его в пригодный для просмотра и анализа вид и складывает результат обратно. Вынесены в отдельную группу, потому что требуют специфического окружения и дают тяжёлую неравномерную нагрузку — обработка одной модели занимает несоизмеримо больше времени, чем любой интерактивный запрос. В манифестах кластера этих компонентов нет: группа обслуживается вне GitOps-контура платформы.
Платформа
Общие механизмы, на которые опираются все прикладные домены: единая точка входа в интерфейс, вход и права, справочник атрибутов, рабочие пространства и проекты как контейнеры данных, журнал действий, уведомления, оркестрация процессов.

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

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

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

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

Единственная группа с существенной вычислительной нагрузкой: обработка вынесена на отдельные узлы, потому что её всплески не должны мешать интерактивной работе остальных сервисов.
L1. Как читать схемы
Легенда нотации. Показан настоящий фрагмент модели, подписанный по типам: каждый элемент и каждая линия здесь встречаются на остальных представлениях в том же начертании.
Стрелка serving читается не как «кто кого вызывает», а как «кто без кого не работает»: она идёт от обслуживающего к обслуживаемому. Направление выбрано так потому, что от схемы обычно нужен ответ на вопрос «что откажет, если убрать этот элемент», — и он читается по стрелкам вперёд.
Узел (Node) — вычислительная среда: кластер, группа серверов или отдельный хост. Ромб на линии — composition: узел состоит из этого, и отдельно от узла содержимое не существует.
Системное ПО (System Software) — платформенный компонент внутри узла. Пунктир с полым треугольником — realization: компонент реализует технологический сервис.
Технологический сервис (Technology Service) — что платформа даёт приложениям, без указания, чем именно это сделано. Приложение зависит от сервиса, а не от конкретного продукта под ним.
Прикладной компонент (Application Component) — сервис прикладного слоя. Цветом различаются слои: голубой — прикладной, зелёный — технологический.
Линия с полым ромбом — aggregation: группа объединяет элемент, но тот может существовать и без неё. Так показано, на каких узлах работает системное ПО.
Линия с шариком и закрашенной стрелкой — assignment: узел выделен под компонент, и компонент на нём исполняется.
Смысловая группа (Grouping) — домен прикладного слоя. Тоже aggregation: компонент принадлежит домену по смыслу, а не по месту размещения.
Артефакт (Artifact) — то, что физически лежит в хранилище: файл, образ контейнера, дистрибутив.
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, отдельного представления для них нет.