Какие решения приняли и почему¶

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

Если на каком-то решении ты скажешь «нет, давай иначе» — это именно то, зачем эта страница. Кнопка комментария рядом с каждым блоком.

Порядок не по номерам, а по тому, что важнее обсудить.

1. Двухуровневая платформа: операционка + рыночная аналитика¶

Статус: в работе, рамка зафиксирована, детали продолжают уточняться.

В чём вопрос был. Изначально Dominium задумывался как операционная система для управления коммерческой недвижимостью: учёт, биллинг, договоры, кабинеты. Хороший продукт сам по себе, но точно такой же, какие уже есть на рынке. Возникал вопрос: в чём наше реальное конкурентное преимущество?

Варианты, которые рассматривали.

Вариант A. Делать просто хорошую операционку. Конкурируем за счёт юзабилити, цены, поддержки. Минус: легко скопировать, нет защитной стены.
Вариант B. Делать операционку плюс «фичу аналитики» внутри неё. Минус: это выглядит как дополнение, а не как самостоятельная ценность. Банки такое не покупают, а оно нужно именно банкам.
Вариант C, выбранный. Делать двухуровневую платформу: внизу операционка (собирает данные), сверху рыночная аналитика (монетизирует данные). Между ними сетевой эффект: чем больше данных — тем точнее аналитика — тем интереснее банкам — тем сильнее банки подталкивают заёмщиков использовать Dominium — тем больше данных.

Почему Вариант C. Это уникальная позиция, которую трудно скопировать. Конкуренты могут сделать такую же операционку быстрее и дешевле, но они не получат данные — данные уже у нас. И обратное: мы можем сделать аналитику не на парсинге публичных источников (как делает CoStar в США), а на первичных операционных данных реальных активов. Это даёт точность, которой нет у внешних агрегаторов.

Что это означает на практике. Все будущие решения проектируются с учётом двух уровней. У собственников и арендаторов — операционные кабинеты. У банков и оценщиков — аналитический доступ. Между ними — обезличивание данных, согласия собственников, разделение доступа.

Откуда эта идея пришла. От Никиты — обсуждали по телефону несколько недель назад, когда говорили про скоринг заёмщиков и про то, что банкам нужны реальные данные доходности похожих объектов.

💬 Прокомментировать

2. Модель видимости данных: кто что видит¶

Статус: в работе, финал — после того, как закроется список ролей и матрица прав.

В чём вопрос был. В Dominium одновременно работают несколько типов пользователей с пересекающимися интересами: управляющая компания управляет объектами нескольких собственников, у одного здания может быть несколько собственников, банк-кредитор смотрит за заёмщиком, банк-партнёр получает аналитику. И всё это не изолированные миры — они связаны юридическими отношениями. Вопрос: как описать, кто что видит, без того чтобы каждый раз изобретать правила заново?

Варианты, которые рассматривали.

Вариант A. «Альфа» — видимость через юридические связи. Кто что видит, определяется активными договорами: управляющая компания видит данные собственников, с которыми у неё подписан договор управления, и только пока договор активен. Банк видит заёмщика только пока кредит открыт. И так далее. Плюс: чисто, отражает реальность. Минус: запросы к базе становятся сложнее (нужно проверять цепочки связей).
Вариант B. «Бета» — стандартный подход SaaS: одно поле принадлежности. Каждая запись помечается «принадлежит организации X», и пользователь видит только то, что относится к его организации. Плюс: простые быстрые запросы. Минус: не работает для нашего случая — один и тот же арендный юнит может быть собран из частей нескольких собственников, один договор связывает две организации, аналитические агрегаты не принадлежат никому конкретно.
Вариант C. «Гамма» — гибрид: где можно — стандартное поле, где нельзя — через связи. На простых сущностях («приватных») — поле принадлежности для скорости. На сложных сущностях («переплетённых») — через юридические связи. Плюс: производительность + гибкость. Минус: сложнее поддерживать.

Что выбрано. Финальный выбор открыт — будет сделан после того, как выпишем полный список ролей. Промежуточная гипотеза — гибрид (C) с уклоном в «через связи» (A).

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

Введён принцип агрегированной видимости: где у роли нет права видеть индивидуальные данные, мы не отказываем от показа, а показываем обезличенный агрегат с правилом обезличивания (минимум 5 наблюдений от минимум 3 разных собственников). Так:

Собственник видит свои объекты + микро-бенчмарк по своему зданию (если в здании достаточно соседей для обезличивания).
Банк-кредитор видит своего заёмщика + бенчмарк по зданию заёмщика + бенчмарк по локации.
Банк-партнёр видит макро-бенчмарки по локациям, без индивидуальных данных.

Что это означает на практике. В будущем Dominium собственник зайдёт в кабинет и увидит: «вот ваша ставка 800 руб/м², а медиана по похожим юнитам в этом здании — 1100 руб/м², по району — 1150 руб/м²». Без раскрытия конкретных ставок соседей. Это сильная фича, и она безопасна юридически.

💬 Прокомментировать

3. Двойная иерархия: юнит может быть собран из частей разных ЕГРН¶

Статус: принято.

В чём вопрос был. Реальный кейс из нашего портфеля (Кластер 73). ИП-арендодатель собирает один арендный юнит из частей разной правовой природы:

Кусок этажа — арендует у ООО (собственника здания).
Машино-место — владеет напрямую.
Доля общедомового имущества — арендует у ТСН.

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

Варианты, которые рассматривали.

Вариант A. Простая модель: один юнит = один объект ЕГРН = один собственник. Композиты разбиваются на отдельные мелкие юниты. Минус: рушится понятие «то, что я сдаю как одну единицу клиенту». Договор с «Цветами» один, а юнитов три — всё рассыпается.
Вариант B. Хранить юнит и ЕГРН-объект как отдельные сущности, и связывать их многие-ко-многим через специальную таблицу связей. Юнит = то, что сдаётся. ЕГРН = то, что записано в Росреестре. Связь хранит долю площади, долю стоимости, правовое основание (собственность/аренда), держателя права, ссылку на договор-основание. Плюс: точно отражает реальность. Минус: сложнее запросы.
Вариант C. Использовать рекурсивную структуру (юнит может быть «составной» из подюнитов). Минус: на практике получается матрёшка с непонятной семантикой.

Что выбрано — Вариант B.

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

Что это означает на практике. В системе у юнита может быть несколько «корней» в ЕГРН. У каждого корня — своя правовая природа (собственность/аренда), свой держатель права, своя ссылка на договор. Это позволяет описать смешанные композиты, переходы права (арендатор выкупает свою долю — лизинговая связь закрывается, появляется собственническая), а также накладывать инварианты («сумма долей собственников по конкретному ЕГРН всегда равна 100%»).

💬 Прокомментировать

4. Единая модель контрагента: одна таблица, разные роли¶

Статус: принято.

В чём вопрос был. В системе много типов «лиц»: собственник, арендатор, банк, управляющая компания, ТСН, оценщик, государственные органы. Изначально логика подсказывала сделать для каждой роли свою таблицу.

Варианты, которые рассматривали.

Вариант A. Отдельные таблицы: собственники, арендаторы, банки, управляющие_компании и т.д. Плюс: каждая роль изолирована. Минус: одна и та же организация может выступать в нескольких ролях одновременно (банк — и кредитор, и партнёр по аналитике; собственник — и арендодатель, и арендатор у соседа). Дублирование, рассинхронизация данных.
Вариант B, выбранный. Одна таблица Контрагенты, и роли описываются через связи (договоры, права собственности, кредитные соглашения). Один юрлицо — одна запись. В каких ролях он выступает — определяется тем, какие у него активные связи в данный момент.
Вариант C. Иерархия с наследованием: базовый «Контрагент», и подтипы «Собственник», «Арендатор» и т.д. Минус: то же дублирование, что в A. Не решает проблему мультиролей.

Почему Вариант B. Реальная экономика — это сеть отношений, не каталог типов. Газпромбанк сегодня кредитует одного собственника, завтра кредитует другого, послезавтра покупает у нас аналитику, после-послезавтра управляет залоговым активом — это один Газпромбанк, и в системе он должен быть одной записью. Иначе при любом изменении нужно править в нескольких местах.

Что это означает на практике. В системе одна таблица контрагентов. У каждого — реквизиты, контакты, история. Все возможные роли (кредитор, заёмщик, арендатор, арендодатель, собственник, партнёр и т.д.) — это связи, а не свойства. Запись «Газпром» живёт независимо от того, какая у него роль сегодня.

Маленькая, но важная деталь: введён флаг «может ли организация иметь пользователей в системе». Например, реальный банк-партнёр имеет учётки сотрудников, а арендатор-физлицо — нет (он только сторона договора).

💬 Прокомментировать

5. Журнал событий с цифровыми подписями: ничего не теряется¶

Статус: принято.

В чём вопрос был. В системе будут происходить изменения, которые потом могут быть оспорены: новые договоры, изменения ставок, переходы прав, переоценки. Если оппонент скажет «такого не было» или «было иначе» — нам нужно уметь доказательно показать, что и когда происходило.

Варианты, которые рассматривали.

Вариант A. Стандартная таблица — текущее состояние плюс отдельная таблица «история изменений», в которой можно копаться. Минус: историю можно править задним числом. Не доказывает, что было именно так.
Вариант B, выбранный. Журнал событий (event sourcing): каждое изменение в системе — это отдельная неизменяемая запись с временной меткой и цифровой подписью. Текущее состояние любой сущности — это результат проигрывания всех событий, которые её касаются. Удалить или переписать запись задним числом нельзя — будет видно сразу.
Вариант C. Использовать блокчейн. Минус: избыточно для нашей задачи, дорого, сложно. Криптографическая подпись каждой записи решает ту же проблему дешевле и проще.

Почему Вариант B. Это банковский стандарт работы с критичными данными. Если в будущем кто-то оспорит решение, мы покажем точную хронику — что произошло, когда, с какой подписью. Через год после выдачи кредита банк сможет показать заёмщику ровно тот бенчмарк рынка, который видел в день выдачи. Это закрывает огромный класс претензий.

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

💬 Прокомментировать

6. NET-pricing: все ставки храним без налогов¶

Статус: принято.

В чём вопрос был. Когда собственник сдаёт юнит за 1 200 000 руб в месяц — что это: с НДС или без НДС? С налогом на УСН или нет? Если хранить «как есть в договоре», начинаются ужасы при сравнении: один юнит сдан с НДС, другой без, и среднюю ставку посчитать корректно нельзя.

Варианты, которые рассматривали.

Вариант A. Хранить «как в договоре» (с НДС, если в договоре с НДС; без — если без). Налоговую составляющую считать отдельно при необходимости. Минус: невозможно сравнивать ставки между собственниками с разными режимами налогообложения.
Вариант B, выбранный. Хранить все суммы NET (без налогов). Налог считается отдельной операцией в момент выставления счёта или отчёта. Договорной валовый платёж = NET + налог.
Вариант C. Хранить и то, и другое (двойная запись). Минус: дублирование, риск рассинхронизации.

Почему Вариант B. Аналитика, бенчмарки, KPI собственников — всё должно быть в одних единицах. NET — это единый знаменатель для сравнимости.

Что это означает на практике. В любой ставке, любом счёте, любом отчёте суммы лежат NET. Налог считается поверх по правилам конкретного режима налогообложения собственника. На интерфейсе пользователю показывается то, что он ожидает (с НДС или без), но внутри хранится NET.

💬 Прокомментировать

7. Кадастровая стоимость из Росреестра: как работаем с нестабильным API¶

Статус: принято.

В чём вопрос был. Кадастровая стоимость объектов нужна для расчёта налога на имущество и для сверки с рыночными оценками. Источник — Росреестр. Но их API не имеет гарантированного SLA — то работает, то не работает, то отвечает медленно.

Варианты, которые рассматривали.

Вариант A. Получать кадастровую стоимость только напрямую из Росреестра по запросу. Если не отвечает — ошибка пользователю. Минус: пользователь страдает за чужой нестабильный сервис.
Вариант B. Хранить кадастровую стоимость в нашей базе, обновлять ночами. Если Росреестр недоступен — отдаём последнее известное значение с пометкой «дата последнего обновления». Плюс: пользователь всегда что-то видит. Минус: данные могут быть устаревшие.
Вариант C, выбранный. Гибрид Варианта B + резервные источники: если Росреестр недоступен слишком долго, обращаемся к альтернативным агрегаторам (DaData, парсинг публичных кадастровых выписок). Источник всегда явно указан в данных — пользователь видит «получено из Росреестра» или «получено из DaData» или «парсинг публичной выписки от такой-то даты».

Почему Вариант C. Это рабочий компромисс: пользователь всегда видит какое-то значение, но никогда не вводится в заблуждение «это точное значение от Росреестра» там, где на самом деле резервный источник.

Что это означает на практике. Кадастровая стоимость в Dominium — это всегда связка [значение, источник, дата получения]. На интерфейсе пользователь видит и значение, и пометку источника. При сверках и спорах сразу понятно, на чём основано.

💬 Прокомментировать

8. Технологический стек¶

Техническая деталь

Это решение техническое, для разработчиков. Здесь оно — для полноты картины и для истории, чтобы было видно, почему такой выбор.

Статус: в работе. Финальный выбор — после закрытия Этапа 1.

В чём вопрос был. На каком технологическом стеке писать систему. Вопрос важный: от стека зависит скорость разработки, стоимость инфраструктуры, надёжность, доступность специалистов на рынке.

Варианты, которые рассматривали.

Вариант A. Связка PostgreSQL + ClickHouse. PostgreSQL — для операционной части, ClickHouse — для аналитики. Плюс: специализированные инструменты для каждой задачи. Минус: две системы одновременно, удвоение поддержки.
Вариант B. Только PostgreSQL — и операционка, и аналитика в одной базе, но в разных схемах. Плюс: проще на старте. Минус: PostgreSQL не оптимален для тяжёлых аналитических запросов.
Вариант C. Облачные управляемые сервисы (Yandex Cloud, Selectel). Плюс: меньше работы по поддержке инфраструктуры. Минус: привязка к поставщику, затраты предсказуемее но в среднем выше.

Что выбрано. Открыто — финал после того, как закроется модель данных Этапа 1. Тогда будет понятна реальная нагрузка и можно будет осознанно выбирать.

Промежуточная гипотеза. Стартовать на чистом PostgreSQL (Вариант B), на старте этого хватит. Когда аналитика станет достаточно тяжёлой — мигрировать на PostgreSQL + ClickHouse (Вариант A). Это даёт быстрый старт и осмысленный путь развития, без переусложнения на ранних этапах.

Что это означает на практике. Решение откладывается осознанно. Пока модель данных не зафиксирована, выбирать стек преждевременно. После закрытия Этапа 1 — сядем, посмотрим на нагрузочные характеристики, выберем.

💬 Прокомментировать

9. AI-Native архитектурный слой¶

Статус: Принят — рамка зафиксирована, наполнение продолжается.

В чём вопрос был. В первоначальной версии ТЗ AI/ML был обозначен одной строкой в плане работ Фазы 2 — общим пунктом «прогноз оттока, прогноз вакансии, аномалии». Это типичный для классических ERP подход: AI как набор отдельных фич, прикрученных к существующей системе после её основной разработки.

В апреле 2026 при обсуждении позиционирования продукта стало ясно, что для Dominium это упущенная возможность. Анализ рынка PropTech показал: AI в брокеридже и оценке (HouseCanary, Skyline AI, Cherre) развит, но в сегменте Asset Management / Property Management для коммерческой недвижимости — ниша почти пустая, особенно на российском рынке. Это окно для позиционирования Dominium как AI-Native платформы, а не как ещё одного ERP с AI-фичами.

Архитектура Dominium изначально содержит то, что для AI-подхода является нативным преимуществом: Event Sourcing (каждое событие в системе автоматически становится тренировочным сигналом без дополнительного ETL), единая модель контрагента (целостная картина субъекта как собственника, арендатора, заёмщика), двойная иерархия Юнит ↔ ЕГРН (правильная единица анализа), двухуровневая платформа (операционные данные + обезличенные рыночные агрегаты). Большинство конкурентов вынуждены строить ML-pipeline поверх классических CRUD-баз, теряя историю изменений. В Dominium этот шаг не нужен.

Варианты, которые рассматривали.

Вариант A. Оставить AI/ML как было — общий пункт в Фазе 2. Минус: не использует архитектурные преимущества Dominium, упускает окно AI-Native позиционирования. Document AI и AI-копилот в Telegram — это снятие барьеров внедрения, не «фича на потом»: без них миграция с Excel/1С остаётся мучительной, Telegram-бот превращается в очередную форму со списками.
Вариант B. Выделить AI/ML в отдельный архитектурный слой на Этапе 0. Плюс: использует Event Sourcing, единую модель контрагента, двойную иерархию как нативный субстрат для AI; формирует позиционирование AI-Native платформы; Document AI и AI-копилот в MVP снимают барьеры внедрения с первого дня. Минус: расширение состава работ MVP, возможна потребность в роли ML Engineer с месяца 5–6; зависимость от внешних LLM-провайдеров (или от инфраструктуры self-hosted моделей).
Вариант C. Спроектировать AI-первый продукт — каждое действие через LLM, классические интерфейсы как fallback. Минус: в финансовом домене (договоры, начисления, банковский мониторинг) необходима детерминированность и объяснимость; AI-первый подход создаёт риски галлюцинаций и непредсказуемого поведения. Гибридная модель (AI как слой над детерминированной системой) — правильный баланс для B2B продукта.

Что выбрано. Вариант B. AI/ML выделяется в отдельный архитектурный слой уже на Этапе 0 — наравне с моделью данных, сетью партнёрств и аналитической платформой. Не как фича, не как «то, что добавим потом», а как структурное свойство продукта.

Почему. Слой делится на две категории — по горизонту запуска и по типу зависимости от данных.

AI-Native MVP — то, что включается с первого дня и работает на любом масштабе данных:

Document AI для импорта договоров. Извлекает структурированные поля (стороны, площадь, ставка NET/GROSS, индексация, депозит, особые условия) из PDF и сканов существующих договоров аренды нового клиента. Без этого миграция с Excel/1С на Dominium остаётся главным барьером внедрения. Workflow: загрузка PDF → автоизвлечение → проверка человеком → создание «живого договора» в системе.
AI-копилот в Telegram-боте управляющего. Распознаёт свободный текст и голосовые сообщения и предлагает структурированные записи (ежедневный отчёт, показ, инцидент, намерение арендатора). Управляющий пишет одной фразой или говорит 15 секунд вместо заполнения пяти форм с десятками полей. Это и есть «магический момент» для управляющего, который сложно скопировать классическим ERP.
LLM-обёртка над конструктором сценариев. Собственник формулирует сценарий естественным языком («что будет, если уйдут два крупнейших арендатора и я подниму ставки на 8%»), система раскладывает в параметры sandbox, запускает расчёт, возвращает разбор со ссылками на конкретные договоры и метрики. Сценарное моделирование, для которого раньше нужен был аналитик и день работы — за минуту, голосом или одной фразой.

AI-Enhanced — расширение Этажа 3 аналитической платформы (см. Решение 1 про двухуровневую архитектуру). Включается при достижении критической массы данных в регионе:

Прогнозный Tenant Health Score (вероятность съезда арендатора за 3/6/9 месяцев).
Прогноз вакансии и достижимой ставки.
Обнаружение аномалий в счётчиках (утечки, скрытое потребление, несанкционированная субаренда) и платежах (ранние сигналы кассового разрыва).
Контекстная приоритизация алертов под роль.
Авто-черновики комментариев для банковского аналитика по отклонениям метрик.

Что осталось намеренно открытым. Конкретный LLM-провайдер не выбран. Индустрия меняется месячными циклами — фиксировать вендора в апреле 2026 для модулей, которые будут разрабатываться через 6–9 месяцев, преждевременно. Архитектурный слой инференса проектируется так, чтобы смена провайдера была конфигурационной операцией, а не архитектурной. Кандидаты для трекинга: облачные API (YandexGPT, GigaChat, Anthropic Claude, OpenAI), self-hosted открытые модели (Llama, Qwen, DeepSeek), гибридные сценарии. Решение принимается ближе к точке внедрения соответствующих модулей.

Принципы работы AI-слоя. Шесть принципов, которые остаются неизменными независимо от выбора провайдера и моделей:

AI как слой, не как фича сбоку. AI-возможности проектируются вместе с моделью данных, не приклеиваются после.
Провайдер-агностичность. Все обращения к LLM/ML идут через внутренний инференс-слой. Смена провайдера — конфигурация, не архитектура.
Human-in-the-loop по умолчанию. AI создаёт черновики и подсказки, человек принимает решение. Особенно строго — для всего, что касается денег, юридических обязательств, общения с арендаторами и банком.
Объяснимость. Любой AI-вывод сопровождается ссылками на исходные данные. Чёрный ящик недопустим для B2B продукта в финансовом домене.
Деградация без AI. Все AI-фичи имеют fallback на классические механизмы. Падение LLM-провайдера не должно останавливать операционную работу.
Защита персональных данных. Договоры и переписка содержат ПДн. Архитектура изначально проектируется с учётом возможной необходимости держать чувствительные операции на self-hosted моделях. Маскирование ПДн перед отправкой в облачные API — обязательная функция инференс-слоя.

Что это означает на практике.

Для банка-партнёра (аналитическое партнёрство): AI-Enhanced модели работают на агрегированном слое и помогают формулировать инсайты по портфелю. Авто-черновики комментариев для аналитика — снимают рутинную часть работы.
Для банка-кредитора (мониторинг ипотеки): AI-Enhanced модели дают раннее предупреждение по ковенантам через прогноз DSCR и vacancy.
Для дистрибуционных партнёров (ОПОРА, БизнесПрокачка и т.п.): AI-Native MVP — это материальный аргумент, объясняющий, почему собственник хочет именно Dominium, а не «что-нибудь учётное».

Где детали. Архитектурное обоснование, шесть принципов, разделение AI-Native vs AI-Enhanced, риски и митигации зафиксированы в decisions/ADR-009-ai-architecture-layer.md. Решение по выбору LLM-провайдера и список кандидатов — в decisions/ADR-010-llm-provider.md. Продуктовое отражение — в docs/prd.md (раздел 6 решение №9, разделы 1, 8, 14, 15, 16, 18, 19) и docs/product-vision.md.

💬 Прокомментировать

— Рома