Технические вопросы¶

Это страница «для полноты картины». Здесь — технические вопросы, на которые мне ответы не нужны от тебя (это решается на уровне разработки), но они зафиксированы — чтобы был виден подход: каждый вопрос проработан, у каждого есть варианты, у каждого виден статус.

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

Без кнопок комментариев — здесь только чтение. Если по какому-то вопросу есть мысль — пиши в Telegram напрямую.

Цвета статусов:

✅ Закрыто — решение принято, виден ход рассуждений.
⏳ В работе — варианты зафиксированы, решение откладывается до определённой стадии.

Часть 1: Закрытые вопросы¶

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

✅ Атрибуты типов юнитов — как хранить (Q-001)¶

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

Варианты.

A — общие поля колонками + специфические в JSONB-поле с валидацией по схеме.
B — отдельная таблица под каждый тип юнита.
C — гибрид (то же что A на практике).

Решение — A.

Один общий справочник типов юнитов, у каждого типа — своя схема валидации для JSONB-поля. Новый тип юнита (например, «навигационная стела») добавляется записью в справочнике, без миграций и переделки кода. Подтверждено реальным кейсом «навигационные стелы» на Кластере 73.

✅ Двойная иерархия — модель связи Юнит ↔ ЕГРН (Q-005)¶

Контекст. Один юнит может объединять несколько объектов в ЕГРН (композит), один объект ЕГРН может питать несколько юнитов (нарезка). Нужна схема хранения связи и долей.

Варианты.

A — отдельная таблица связи Юнит-ЕГРН с площадью и стоимостной долей.
B — упрощённая ссылка «юнит к одному ЕГРН» + отдельная таблица для нарезок.
C — каждый юнит принадлежит ровно одному ЕГРН, композиты — через «контейнерные юниты».

Решение — A.

Зафиксировано как архитектурное решение. Подтверждено на четырёх реальных объектах нашего портфеля, включая дополнительный сложный кейс «один ЕГРН проходит через несколько арендных помещений».

✅ Связь пользователь ↔ контрагент (Q-006)¶

Контекст. Пользователь системы (логин, пароль) и контрагент (юр./физ. лицо в бизнесе) — это разные сущности. Один пользователь может представлять одного контрагента (собственник со своей учёткой), может никого не представлять (системный администратор), а контрагент может быть в системе без пользователя (арендатор-физлицо).

Варианты.

A — необязательная ссылка с пользователя на контрагента (один к нулю-одному).
B — связочная таблица «многие-ко-многим» (один пользователь представляет несколько лиц).
C — пользователь наследуется от контрагента.

Решение — A.

В реальности 95% случаев — это либо сотрудник управляющей компании (без связи с контрагентом), либо собственник со своей учёткой (один к одному). Случай «один пользователь представляет несколько лиц» в нашей практике не встречался.

✅ Композитный юнит — рекурсия или через таблицу связей (Q-007)¶

Контекст. Когда юнит составной (4 машино-места + доля общедомового имущества + рекламное место), как это выражать в данных — через рекурсивную ссылку «юнит к юниту» или через множественные связи юнита с разными объектами ЕГРН?

Варианты.

A — только через таблицу связей Юнит-ЕГРН, без рекурсии.
B — рекурсивная ссылка «родительский юнит».
C — гибрид.

Решение — A.

Композиция уже выражена через двойную иерархию (см. соответствующее решение). Жизненный цикл композитного юнита — это операции «разделить / слить / пересобрать», которые создают новые юниты и закрывают старые. Это не работа с дочерними под-юнитами. «Пакеты» арендаторов (один арендатор берёт юнит + рекламу + машиноместо) оформляются тремя отдельными договорами — связь на уровне контрагента, а не юнита.

✅ Единая модель контрагента (Q-008)¶

Контекст. Один реальный субъект (юр.лицо или человек) может одновременно быть собственником одного объекта, арендодателем по одному договору, арендатором по другому. Нужна единая сущность с ролями или раздельные таблицы для каждой роли.

Варианты.

A — единый Контрагент для всех ролей.
B — раздельные Собственник, Арендатор, Конечный пользователь.
C — Контрагент плюс наследники.

Решение — A.

Зафиксировано как архитектурное решение. Подтверждено на реальных кейсах: одно юрлицо в разных ролях, цепочки субаренды (ООО → ИП → конечный арендатор), один арендатор в нескольких юнитах, мультивладение.

✅ Справочник правовых форм владения (Q-016)¶

Контекст. В Гражданском кодексе перечислено несколько форм права на недвижимость: собственность, хозяйственное ведение, оперативное управление, пожизненное наследуемое владение, постоянное пользование, долгосрочная аренда. Какие из них поддерживать в справочнике на старте?

Варианты.

A — полный справочник, все формы из ГК РФ.
B — только базовый набор (собственность, долгосрочная аренда).
C — список в коде, не отдельный справочник.

Решение — B.

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

✅ Портфель — единственный собственник или мультивладение (Q-018)¶

Контекст. На реальных объектах с несколькими собственниками (Кластер 73, Нововатутинская) в одном здании несколько владельцев ЕГРН. Что такое «портфель» в системе — портфель управляющего или портфель совладельцев?

Варианты.

A — портфель принадлежит одному контрагенту (управляющему). Мультивладение выражается на уровне отдельных объектов ЕГРН, не портфеля.
B — портфель может принадлежать нескольким контрагентам с долями.
C — портфель без явного владельца, просто группировка для интерфейса.

Решение — A.

Реальный портфель из четырёх объектов — это контур управления одной компании, не контур владения. Управляющий и собственник конкретного объекта — разные сущности, и это нормально. Мультивладение корректно выражается на уровне отдельных объектов ЕГРН, где у каждого свой набор долей собственников. Дублировать «владение портфелем» избыточно.

Часть 2: Открытые технические вопросы¶

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

⏳ Битемпоральная схема — как реализовать историю изменений (Q-002)¶

Нужна общая стратегия для версионирования всех сущностей, которые изменяются во времени: договоры, юниты, объекты ЕГРН, оценки, налоговые режимы. Три варианта рассматриваются: пары колонок «действует с / по» в каждой таблице; отдельные таблицы истории; единый журнал событий с проекциями. Решение — после детализации раздела про версионирование.

⏳ Снимки состояния для журнала событий (Q-003)¶

Журнал событий хранит каждое изменение, но для скорости нужны промежуточные снимки. Когда их создавать — каждые N событий на сущность, по расписанию или по нагрузке? Решение — после детализации раздела про события.

⏳ Согласование списка ролей (Q-004)¶

В исходном техзадании 11 ролей, в процессе работы добавились 3 системных, часть бизнес-ролей возможно избыточна. Объединить в 14, оставить 11 + системные отдельно или пересмотреть с нуля. Этот вопрос частично перекрывается с партнёрским вопросом 6 — финальное решение учтёт обратную связь от Никиты.

⏳ Полиморфная ссылка в журнале событий (Q-009)¶

Журнал событий — это универсальный «контейнер» для всех сущностей. Поле «к чему относится событие» должно ссылаться на любую сущность системы. В реляционной базе это выражается несколькими способами. Текущая рабочая гипотеза — пара полей «тип сущности + идентификатор» с проверкой на уровне приложения. Решение — при детализации раздела про события.

⏳ Ставка капитализации — где живёт в модели (Q-010)¶

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

⏳ Отчёты управляющих, показы, инциденты, намерения арендаторов (Q-011)¶

Эти модули поступают через Telegram-бота от управляющих. Моделировать их как полноправные сущности (со своими таблицами и жизненным циклом) или как специализированные события в общем журнале? Решение — при наполнении соответствующих разделов.

⏳ Домен уведомлений — место в архитектуре (Q-012)¶

Уведомления (правила алертов, сами алерты, история отправок) — отдельный домен с собственными сущностями или проекции поверх общего журнала событий? Решение — при детализации раздела про события.

⏳ Признак валюты — где хранить (Q-013)¶

В первой фазе — только рубли. Хранить признак валюты в каждой денежной таблице с самого начала (на будущее) или добавить миграцией позже? Текущая гипотеза — хранить на уровне договора и счёта, не в каждой строке. Решение — при детализации биллинга.

⏳ Адрес здания — текст или структура (Q-014)¶

Адрес можно хранить свободным текстом (просто, гибко) или структурой (город, улица, дом, корпус). Текст проще, структура нужна для интеграций с геокодированием и поиском. Текущая гипотеза — текст плюс кэш геокодирования. Решение — при детализации интеграций.

⏳ Координаты здания (Q-015)¶

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

⏳ Состав справочника единиц тарификации (Q-017)¶

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

⏳ Банковские реквизиты — встроенное поле или отдельная таблица (Q-019)¶

У одного контрагента может быть несколько счетов (рублёвый, валютный, отдельные для разных арендаторов). Хранить массив в JSON-поле или отдельной таблицей с историей и пометкой «основной»? Текущая гипотеза — отдельная таблица, единый стиль с другими атрибутами контрагента. Решение — при детализации счетов.

Что в этом видно¶

Подход одинаковый везде, не только в больших архитектурных развилках:

Каждый вопрос проработан до уровня вариантов — никаких «потом разберёмся».
Каждый имеет рабочую гипотезу — даже если решение откладывается, мы знаем, куда движемся.
Никаких решений не принимается заранее там, где это требует контекста. Закрываем вопрос только когда понятно, что закрытие не подвинется через неделю.
Закрытые вопросы документируются с обоснованием, а не просто «выбрано B».

Это и есть та самая хроника, на которую опирается главная идея проекта — что вся история построения остаётся видимой и защитимой.

— Рома