Nimbus Docs

Appearance

Вопросы партнёру по коммерческому предложению ​

Документ подготовлен для защиты архитектурного фундамента проекта Nimbus (биллинговая система ЖКХ) и выявления обоснованности предложения о «реализации с нуля».

Уважаемый партнёр,

Благодарю за коммерческое предложение. Чтобы двигаться дальше, мне важно согласовать ряд технических и организационных аспектов. Ниже — вопросы, сгруппированные по темам. Буду признателен за подробные ответы.

1. Аудит текущей архитектуры ​

1.1 Структуры данных и БД ​

В проекте уже реализованы и используются следующие сущности и модели:

  • Лицевые счета (PersonalAccount) — связь с Room, Owner, поля AccountNumber, OpeningDate, ClosingDate, поддержка нескольких собственников.
  • Долевая собственность (RoomOwner) — таблица room_owners с share_numerator, share_denominator, is_responsible, valid_from, valid_to. Миграция 001_room_owners.sql и модель RoomOwner в room_owner.go.
  • Начисления (Charge) — модель с CalculationJobID, PersonalAccountID, HouseServiceID, Period, RateType, TariffValue, Area, Consumption, Amount, CalculatedAt.
  • Счётчики — полиморфная модель Meter (OwnerType + OwnerID) для ИПУ и ОДПУ, MeterReading, MeterPeriod, справочники MeterType, MeterStatus.
  • Услуги и формулы — UtilityService с полем CalculationFormulaCode, UtilityServiceFormulaFlags (JSONB) для модификаторов (повышающий коэффициент, отрицательный ОДН, методы ОДН и т.п.).
  • Справочники — ОКОПФ, ОКАТО, типы домов, типы отопления, водоснабжения, канализации, виды услуг, единицы измерения, правила расчёта, ГИС ЖКХ.

Вопросы:

  1. На основании какого аудита вы предлагаете разрабатывать структуры данных «с нуля»? Можете ли вы прислать конкретные замечания к существующей схеме (список таблиц/моделей и проблем)?
  2. Какие именно ограничения текущей модели room_owners (долевая собственность, период действия, ответственный собственник) вы считаете неустранимыми при масштабировании?
  3. Как ваша инфология будет обрабатывать полиморфную связь счётчиков (ИПУ ↔ лицевой счёт, ОДПУ ↔ дом), которая уже реализована в Meter?
  4. Готовы ли вы включить в договор пункт о проведении технического аудита существующей БД до начала проектирования «с нуля», чтобы зафиксировать, что именно не устраивает?

2. «Золотой тест» и бизнес-логика Постановления №354 ​

В проекте реализован «золотой тест» на 12 месяцев (golden_test_jkh_12months.xlsx, генератор generate_golden_test_jkh_12months.py, seed seed_golden.go) с 10 лицевыми счетами и следующими сценариями:

ЛСОписание
LS02Отсутствие показаний: март–май — по среднему, июнь — по нормативу (п. 59, 60 ПП 354)
LS07Изменение услуг: парковка отключается с 15 июля (pro-rata 15/30)
LS08Отопление по ОДПУ, формула 3(3) — распределение Гкал: ОДПУ_гкал × (площадь_ЛС / площадь_дома)
LS09Неисправный ИПУ — сентябрь: норматив × 1.5 (п. 60, 61)
LS10Отрицательный ОДН — если ΣИПУ > ОДПУ, то ОДН = MAX(0, ОДПУ − ΣИПУ) = 0

В UtilityService реализованы коды формул ПП 354: pp354_formula_1, pp354_formula_4, pp354_formula_1_or_4, pp354_formula_2, pp354_formula_2_1, pp354_formula_3, pp354_formula_3_1, pp354_formula_3_3, pp354_formula_10_11, pp354_formula_10_12, pp354_formula_10_15, pp354_formula_20, pp354_formula_23. В UtilityServiceFormulaFlags предусмотрены модификаторы: AllowNegativeConsumption, WithIncreasingCoefficient (Kпов = 1.5), правила ОДН, методы расчёта отопления и т.д.

Расчёт отопления реализован через двухуровневую модель: (1) базовый код формулы (CalculationFormulaCode: pp354_formula_2, 2_1, 3, 3_1, 3_3) определяет способ расчёта (по площади, по ОДПУ, с ИПУ и т.д.); (2) дополнительные модификаторы в UtilityServiceFormulaFlags и HouseService — HeatingPaymentMethod (в отопительный период / равномерно в течение года), SubtractHeatingWater (вычет объёма на нагрев воды: none, upper_bound, lower_bound, lower_bound_with_odn), HeatingHasCommonAreaHeating. Параметры могут переопределяться на уровне дома через HouseService.

Вопросы:

  1. Как ваша инфология будет обрабатывать кейс LS10 (отрицательный ОДН): ΣИПУ > ОДПУ → ОДН = 0? Планируете ли вы явно описывать такие правила в спецификации?
  2. Как вы планируете реализовывать расчёт отопления — через отдельные коды формул на каждую комбинацию, через базовую формулу + модификаторы (как сейчас), или иным способом? Какой подход считаете предпочтительным и почему?
  3. По какой причине вы считаете текущую модель расчёта (код формулы + модификаторы в JSONB) неработоспособной или непригодной? Просим привести конкретные ограничения или недостатки, а не общие формулировки.
  4. Готовы ли вы использовать наш golden test как обязательный регрессионный набор для приёмки расчётов (LS01–LS10, 12 месяцев)?
  5. Планируется ли переиспользование существующих алгоритмов расчёта и кодов формул ПП 354, или вы предполагаете реализовать их заново? Если заново — какой документ/спецификацию вы возьмёте за основу?
  6. Как в вашей модели будут отражены краевые случаи: неисправный ИПУ (норматив × 1.5), отсутствие показаний (среднее → норматив после 3 месяцев), распределение ОДПУ по формуле 3(3)?

3. Технологический стек и инфраструктура ​

Текущий стек проекта:

КомпонентТехнология
BackendGo 1.23+, Gin, GORM
AuthJWT, Redis (сессии, 2FA)
FrontendReact, TypeScript, Vite, MUI, Recharts
СУБДPostgreSQL 15/16
ИнфраструктураDocker, Docker Compose
ХранениеAWS S3 (для биллинговых данных)

В предложении не указаны конкретные технологии для этапа «реализации с нуля».

Вопросы:

  1. Какой язык программирования, фреймворк и СУБД планирует использовать ваш программист на этапе разработки?
  2. Совпадают ли они с текущим стеком (Go, Gin, GORM, PostgreSQL)? Если нет — как вы планируете стыковать новый код с уже развёрнутой инфраструктурой и микросервисами (auth, core, billing)?
  3. Как будет организована миграция с существующей БД (nimbus_auth, nimbus_core, nimbus_billing) на новые структуры, если вы предлагаете их переделать?
  4. Готовы ли вы зафиксировать технологический стек в приложении к договору, чтобы исключить смену стека в процессе работ?

4. Интеллектуальная собственность и прозрачность ​

Вопросы:

  1. Кому будут принадлежать права на исходный код, архитектуру и документацию после завершения этапа разработки: заказчику, исполнителю или на условиях совместного владения?
  2. Будет ли заказчику передан полный исходный код (включая миграции, seed-скрипты и конфигурацию) без ограничений на дальнейшее использование?
  3. Планируется ли использование сторонних библиотек/компонентов с лицензиями, ограничивающими коммерческое применение (GPL, AGPL и т.п.)?
  4. Как будет решаться вопрос прав на текущую кодовую базу (модели, golden test, seed-данные): остаётся ли она полностью в собственности заказчика и не будет ли «размываться» при интеграции с новым кодом?

5. Информационная безопасность ​

В проекте уже реализован ряд мер защиты:

  • Аутентификация: JWT-токены (Access 15 мин + Refresh 7 дней), хранение в httpOnly cookies (защита от XSS), blacklist отозванных токенов в Redis.
  • Пароли: хеширование bcrypt (cost 12), защита от timing-атак при проверке несуществующего пользователя.
  • Авторизация: RBAC (Role-based access control), проверка ролей на сервисах.
  • 2FA: опциональная двухфакторная аутентификация (TOTP), endpoints /auth/2fa/setup, /auth/2fa/verify-setup, /auth/2fa/verify-login, /auth/2fa/disable.
  • Защита от брутфорса: rate limiting на логин (Redis), блокировка по username после неудачных попыток, логирование попыток входа.
  • Сеть: CORS с явным whitelist origins, HTTPS в production (Caddy + Let's Encrypt), редирект HTTP → HTTPS.
  • Секреты: JWT_SECRET из файла (не в коде), разделение dev/prod конфигурации.
  • Данные: soft delete, логирование событий безопасности (metrics).
  • Документация: SECURITY_RECOMMENDATIONS.md, JWT_COOKIES_IMPLEMENTATION.md, 2FA_IMPLEMENTATION.md, RATE_LIMITING_IMPLEMENTATION.md, SECURITY_AUDIT_REPORT_2025-11-17.md.

Вопросы:

  1. Включён ли в этап 1 (проектирование) аудит информационной безопасности и соответствия 152-ФЗ (персональные данные)?
  2. Планируется ли сохранить и развивать существующий подход к аутентификации (JWT + 2FA + rate limiting) или предлагается замена на другой стек?
  3. Как в новой архитектуре предполагается обеспечивать защиту персональных данных собственников и плательщиков (адреса, ФИО, ИНН, показания счётчиков)?
  4. Есть ли у вашей команды опыт аттестации ИС по требованиям ФСТЭК/ФСБ или подготовки к проверкам регуляторов в сфере ЖКХ?

Заключение ​

Я ценю ваш опыт и заинтересован в сотрудничестве при условии, что:

  • будет учтён существующий архитектурный фундамент,
  • «реализация с нуля» будет обоснована техническим аудитом,
  • golden test и алгоритмы ПП 354 будут сохранены или явно переработаны по согласованной спецификации,
  • меры информационной безопасности (аутентификация, 2FA, rate limiting, защита ПДн) будут сохранены или явно улучшены,
  • права на код и архитектуру будут чётко зафиксированы в договоре.

Прошу направить ответы в том же структурированном виде. Готов обсудить детали на созвоне.

С уважением,
[Ваше имя]