Дх4RU

Теперь включаем нашу архитектуру:

Кристалл = 3 уровня

Узлы (сущности)

• Производитель: Дх4Ру
• Продукты: смеси, покрытия, инструмент
• Объекты: метро, Магнит, парковки
• Клиент: Союз единоборцев

👉 Это уже реестр узлов

Рёбра (связи)

• Материалы → применены в проектах
• Компания → поставщик
• Объекты → подтверждение качества
• Клиент → потенциальный заказчик

👉 Это граф связей (Graph DB)

Кристалл (система)

Теперь всё это становится:

👉 цифровым паспортом компании + продуктов + кейсов

Как это должно выглядеть в ЕДИНОМ ПОРТАЛЕ

Вот ключевой момент. Сейчас — бумага. У нас — должна быть живая цифровая система.

Вместо письма: Профиль компании

• рейтинг
• производственные мощности
• сертификация (ISO — уже есть)

Каталог продуктов (не текстом!)

• карточки материалов
• характеристики
• BIM-интеграция
• цена / наличие

Вместо слов: “мы работали на 50 объектах”

👉 Система показывает:

• подтверждённые контракты
• акты
• цифровые следы

Прямая интеграция в рынок

И вот здесь происходит магия:

❌ Было: “Будем рады предоставить информацию”

✅ Станет: “Нажмите — и закажите материалы прямо сейчас”

Перевод письма в цифровую модель

Вот наша схема:

Если внедрить нашу систему: 📌 Этот документ превращается в:

• 1 профиль компании
• 20+ карточек материалов
• 100+ цифровых объектов
• 1 API для заказов

Жёсткая правда (без прикрас)

Сейчас: 👉 это просто маркетинговое письмо

В нашей системе: 👉 это становится активом

И разница огромная:

• письмо = 0 масштабируемости
• система = экспоненциальный рост

Архитектура системы

Главная идея

Письмо — это не документ. Письмо — это неструктурированный входящий сигнал о:

• компании,
• продукции,
• реализованных объектах,
• доверии,
• контакте,
• намерении войти в рынок.

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

Документ → Извлечение сущностей → Реестр → Граф связей → Сервисы → Сделка

Логические уровни архитектуры

Я бы заложил 7 уровней.

Уровень 1. Входящий контур

Сюда попадает всё, что приходит в систему:

• письма
• PDF
• сканы
• коммерческие предложения
• каталоги
• сертификаты
• доверенности
• презентации
• фото объектов

На примере письма:

входящий артефакт — скан письма ООО «Дх4Ру».

Что делает слой:

• загрузка файла
• OCR / парсинг текста
• выделение структуры документа
• определение типа документа

Результат:

система понимает, что это:

• письмо-представление компании,
• с перечислением продукции,
• с кейсами объектов,
• с реквизитами.

Уровень 2. Слой извлечения сущностей

Это ядро первичного интеллекта системы.

Он извлекает:

• Организации: ООО «Дх4Ру»
• ИНН: 9717038195
• Контактные данные
• Продуктовые категории:
• полимерные покрытия
• сухие смеси
• комплектующие
• Объекты/кейсы:
• Московский метрополитен
• Белджи
• Магнит
• парковки ЖК Москвы
• Astana locomotive plant
• Роствертол
• География
• Площади
• Периоды работ
• Получатель письма
• Подписант
• Признаки доверия:
• 30 лет
• ISO
• перечень крупных объектов

На выходе: появляется набор нормализованных сущностей.

Уровень 3. Нормализация и мастер-данные (MDM)

Тут система убирает хаос. Потому что в документах одно и то же пишут по-разному:

• «Московский метрополитен»
• «Метро Москвы»
• «Московское метро»

Система должна понимать, что это один и тот же объект / заказчик / контур проектов.

Что тут происходит:

• дедупликация организаций
• унификация названий
• сопоставление с государственными и отраслевыми справочниками
• проверка реквизитов
• нормализация адресов
• нормализация единиц измерения
• нормализация ролей участников

Результат: возникает единый реестр сущностей.

Базовые реестры системы

Это фундамент. Без этого всё развалится.

Реестр компаний

Карточка компании должна содержать:

• ID компании
• наименование
• ИНН / ОГРН
• тип участника
• производитель
• поставщик
• подрядчик
• проектировщик
• заказчик
• регион
• контакты
• сайт
• производственные мощности
• статусы верификации
• рейтинг доверия
• документы
• связи с продуктами
• связи с объектами

Для этого кейса: ООО «Дх4Ру» = производитель строительных материалов.

Реестр продуктов и материалов

У каждого материала должна быть карточка.

Карточка материала:

• ID продукта
• категория
• наименование
• технические характеристики
• нормативные документы
• сертификаты
• фото
• паспорт продукта
• BIM-атрибуты
• область применения
• производитель
• наличие / логистика
• история применения на объектах

На примере письма:

• полимерные покрытия для пола
• сухие строительные смеси
• декоративные покрытия «Терраццо»
• ножи, диски, фрезы, направляющие, опалубка

Реестр объектов строительства

Это один из главных активов платформы.

Карточка объекта

• ID объекта
• название
• тип объекта
• местоположение
• площадь
• сроки
• статус
• участники
• применённые материалы
• подрядчики
• фото / документы
• цифровой след
• верификация факта участия

На примере:

• Московский метрополитен
• 32 супермаркета «Магнит»
• более 50 паркингов ЖК Москвы
• Роствертол
  и так далее.

Реестр документов

Документ должен жить не отдельно, а как часть графа.

Карточка документа:

• ID документа
• тип
• источник
• дата
• отправитель
• подписант
• связанные компании
• связанные объекты
• связанные продукты
• извлечённый текст
• версия
• статус проверки
• электронный след / хэш

Это письмо: тип = письмо-представление / коммерческое установочное письмо.

Реестр ролей и участников

На одном объекте всегда много участников.

Роли:

• заказчик
• застройщик
• техзаказчик
• генподрядчик
• подрядчик
• поставщик
• производитель
• проектировщик
• эксплуатант
• инвестор

Система должна видеть не просто компании, а кто в какой роли где участвует.

Графовая модель: узлы и рёбра

Вот здесь твоя идея «узлы, рёбра, кристалл» становится настоящей архитектурой.

Узлы

Типы узлов:

• Company
• Product
• Material
• Project
• Object
• Person
• Document
• Certificate
• Region
• Contract
• Role
• Category

Рёбра. Связи между узлами:

• COMPANY_PRODUCES_PRODUCT
• PRODUCT_USED_IN_OBJECT
• COMPANY_PARTICIPATED_IN_OBJECT
• DOCUMENT_MENTIONS_COMPANY
• DOCUMENT_MENTIONS_OBJECT
• COMPANY_HAS_CERTIFICATE
• PERSON_SIGNED_DOCUMENT
• COMPANY_LOCATED_IN_REGION
• OBJECT_LOCATED_IN_REGION
• COMPANY_HAS_ROLE_IN_OBJECT

Пример графа для письма:

ООО «Дх4Ру» → производит → полимерные покрытия

ООО «Дх4Ру» → участвовало в → Московский метрополитен

Полимерные покрытия→ применены на → паркинги ЖК Москвы

Письмо №105/25/Дх→ упоминает → ООО «Дх4Ру»

Письмо №105/25/Дх→ упоминает → Магнит / Белджи / Роствертол

Прикладные сервисы поверх данных

Это уже не хранение, а польза.

Сервис цифрового профиля компании

Показывает:

• кто это,
• чем занимается,
• где применялись материалы,
• какой уровень доверия,
• какие документы подтверждают опыт.

Сервис каталога материалов

Позволяет:

• искать материалы,
• фильтровать по свойствам,
• смотреть реальные объекты применения,
• сравнивать производителей.

Сервис подбора решений

Например: «Нужно покрытие для паркинга 10 000 м² в Москве»

Система выдаёт:

• подходящие материалы,
• поставщиков,
• проверенные кейсы,
• сроки и аналоги.

Сервис доверия и верификации

Проверяет:

• есть ли подтверждение объектов,
• есть ли сертификаты,
• есть ли подтверждённые документы,
• есть ли аномалии в заявленных кейсах.

Сервис сделок / закупки

Это уже переход в маркетплейс:

• запрос образцов
• запрос КП
• тендер
• заказ партии
• логистика
• сопровождение поставки

Технологическая архитектура

Теперь жёстко и предметно.

Frontend. Интерфейсы:

• веб-портал
• личный кабинет компании
• кабинет заказчика
• кабинет оператора платформы
• аналитическая панель
• карточка объекта
• карточка материала
• карточка компании

Подход:

• React / Next.js
• дизайн-система
• роли и состояния
• search-first интерфейс

Backend

Нужен модульный backend.

Основные сервисы:

• Auth Service
• Company Service
• Product Service
• Object Registry Service
• Document Service
• Graph Service
• Verification Service
• Search Service
• Procurement Service
• Notification Service
• Analytics Service

Подход:

• микросервисы или модульный монолит на старте
• API-first
• event-driven интеграция

Для MVP я бы не распылялся и пошёл в модульный монолит, чтобы быстро собрать ядро.

Хранилища данных. Тут нужна не одна база.

Реляционная БД

Для реестров и транзакций:

• PostgreSQL

Хранит:

• компании
• продукты
• объекты
• пользователи
• роли
• документы
• заявки
• сделки

Графовая БД

Для связей:

• Neo4j / Memgraph

Хранит:

• узлы
• рёбра
• цепочки участия
• связи материалов и объектов
• граф доверия

Поисковый индекс

Для быстрого поиска:

• Elasticsearch / OpenSearch

Хранит:

• индексы документов
• полнотекстовый поиск
• фасетный поиск по материалам, объектам, компаниям

Объектное хранилище

Для файлов:

• S3-совместимое хранилище / MinIO

Хранит:

• PDF
• сканы
• фото
• сертификаты
• каталоги

AI / интеллектуальный слой

Без этого система будет просто архивом.

Document AI

Обрабатывает входящие документы:

• OCR
• классификация документа
• извлечение сущностей
• извлечение реквизитов
• извлечение кейсов

Entity Resolution

Определяет: это новый объект или уже существующий?

Считает рейтинг доверия компании на основе:

• подтверждённых объектов
• документов
• сертификации
• полноты профиля
• повторяемости участия в проектах

Knowledge Graph Intelligence

Позволяет отвечать на вопросы:

• где применялся этот материал?
• какие компании реально работали на крупных транспортных объектах?
• кто поставлял решения для паркингов?
• какие материалы доказали масштабируемость?

Событийная модель

Чтобы система была живой, а не статичной.

События:

• CompanyCreated
• DocumentUploaded
• DocumentParsed
• EntityMatched
• ProductCreated
• ObjectLinked
• VerificationRequested
• VerificationApproved
• RFQCreated
• QuoteSubmitted
• ContractRegistered

Это позволит:

• запускать проверки,
• обновлять индексы,
• уведомлять пользователей,
• строить аналитику.

Безопасность и доверенная среда

Для строительной платформы это критично.

Нужно:

• RBAC / ABAC доступы
• журнал действий
• версионность документов
• контроль происхождения данных
• электронная подпись
• хэширование документов
• аудит изменений
• разграничение публичных и закрытых данных

Архитектура экрана на примере этого кейса

Если открыть компанию из этого письма в системе, экран должен быть таким:

Карточка компании

ООО «Дх4Ру»

Блок 1. Общая информация

• ИНН
• сайт
• регион
• тип участника
• дата основания
• статус верификации

Блок 2. Продукты

• полимерные покрытия
• сухие смеси
• терраццо
• комплектующие

Блок 3. Подтверждённые кейсы

• Московский метрополитен
• Магнит
• Белджи
• Роствертол
• ЖК Москвы

Блок 4. Документы

• письмо-представление
• сертификаты
• каталоги
• доверенности

Блок 5. Граф связей

визуальная схема:

Компания ↔ Продукты ↔ Объекты ↔ Документы ↔ Регионы

Блок 6. Действия

• запросить КП
• запросить образцы
• пригласить в тендер
• связаться
• проверить опыт

Минимальный MVP

Не надо сразу строить космический корабль. Надо строить ядро.

MVP v1. Включает только 6 сущностей:

• компании
• продукты
• объекты
• документы
• связи
• заявки

MVP-функции:

• загрузка документа
• извлечение текста
• ручное подтверждение сущностей
• карточка компании
• карточка продукта
• карточка объекта
• граф связей
• поиск
• запрос на контакт / КП

Без лишней романтики. Практично.

Front

• Next.js
• TypeScript

Back

• NestJS или FastAPI
• REST/GraphQL API

Data

• PostgreSQL
• Neo4j
• OpenSearch
• MinIO

AI

• Docker
• Kubernetes позже
• сначала docker-compose / dev cluster
• Keycloak или аналог для IAM

Архитектурная формула нашей системы

В одной фразе:

Единый строительный портал = реестровая платформа + граф связей + интеллектуальная верификация + сервис сделки.

А если в твоей терминологии:

Узлы = сущности

Рёбра = отношения

Кристалл = цифровая операционная модель строительного рынка

Самое важное решение

Не строй систему как «сайт компаний». Это тупиково.

Строй как:

реестр + граф + доказательная среда + транзакционный контур

Тогда даже такое простое письмо становится не архивом, а входом в цифровую экономику строительства.