BSS Layer (Business Support Systems)

Слой BSS отвечает за управление деньгами, продуктами и клиентами. В новой архитектуре мы уходим от микро-фрагментации к более крупным доменным сервисам (Macroservices), чтобы снизить накладные расходы на согласованность данных.

Контекст рынка: Архитектура BSS-слоя спроектирована с учётом лучших практик ведущих ISP-платформ (Hydra Billing, Splynx, BillMax). В отличие от монолитных решений, наш BSS построен как набор слабосвязанных доменных сервисов, каждый из которых владеет своими данными и общается с остальными через Protobuf-контракты и события RabbitMQ.

Роль слоя BSS

BSS — это источник коммерческой правды. Он покрывает полный цикл Order-to-Cash (от заявки до получения денег):

• Кто клиент (персоны/юрлица, договоры, контакты, адреса, каналы продаж, KYC-верификация).
• Что ему продано (продукты, услуги, подписки, параметры услуги, бандлы, аренда оборудования).
• Сколько это стоит и что уже оплачено (баланс, начисления, платежи, задолженность, промо-акции).
• Как удерживать клиента (лояльность, персонализированные предложения, автоматический upsell, churn prediction).

Важно: BSS не "управляет сетью" напрямую. Он управляет договорными обязательствами и инициирует изменения через процессы/команды.

Order-to-Cash Pipeline

Полный бизнес-цикл от первого контакта до регулярного дохода:

Границы ответственности

Чтобы избегать размывания доменов и циклических зависимостей, закрепляем простые правила:

• BSS делает:
  • жизненный цикл клиента/договора;
  • продуктовую модель (каталог, цены, скидки);
  • финансовую модель (ledger, счета, оплаты, dunning);
  • бизнес-уведомления (письма/смс о событиях: счет, долг, подключение).
• BSS не делает:
  • провижининг на оборудовании, настройки профилей AAA;
  • инвентаризацию портов/устройств и их состояние;
  • сбор usage/сетевой телеметрии (это OSS/Mediation).

Владение данными (Single Source of Truth)

Ниже — ориентир, кто владеет сущностью, а кто её только читает/кэширует.

Примечание: OMS (Order Management System) и FSM (Field Service Management) не владеют бизнес-сущностями, а оркестрируют процессы над ними. Подробнее см. Бизнес-сценарии и Оркестрация.

Интеграционные контракты

BSS обычно участвует в процессах в двух режимах.

1) Синхронно (API для чтения и валидации)

Используется, когда нужен быстрый ответ для UI/оператора или для валидации шага оркестрации:

• поиск клиента/договора;
• расчёт предварительной стоимости (quote);
• проверка доступности продукта для клиента/адреса (бизнес-правила).

2) Асинхронно (команды/события для долгих операций)

Используется, когда процесс состоит из нескольких шагов и должен быть устойчивым к ретраям:

• события: payment.received, balance.updated, subscription.activated;
• команды: access.suspend, access.resume, service.activate.

Практика: “деньги” и “продукты” публикуют факты (events), а процессы/OSS получают от них намерения (commands) через оркестрацию.

Надёжность денег (invariants)

Финансовый домен требует строгих гарантий:

• Двойная запись (Double-entry ledger): любая операция = проводки, а не “просто обновили баланс”.
• Идемпотентность платежей: внешний webhook/платёж может прийти повторно — вход должен быть защищён ключом/идентификатором операции.
• Reconciliation: сверка с банком/эквайрингом и восстановление расхождений (отдельный процесс).
• Audit log: неизменяемый журнал критичных действий (изменение тарифа, ручные корректировки, возвраты).

Ключевые сервисы

1. Customer Core Service

Единый источник правды о клиентах и партнерах.

• Объединяет функции:
  • CRM: Профили, контакты, договоры.
  • Address: Проверка технической возможности, зоны покрытия, ФИАС.
  • Partners: Управление дилерами и иерархией реселлеров.
• События: CustomerCreated, ContractSigned, PartnerRegistered.

ConnectRPC API (основные методы):

События (Exchange: isp.events.customer): customer.created, customer.updated, contract.signed, contract.terminated.

2. Product & Subscription Service

Управление коммерческим предложением и жизненным циклом услуг абонента. Аналог модулей Product Catalog в Hydra Billing и Tariff Plans в Splynx.

• Объединяет функции:
  • Catalog: Тарифы, опции, бандлы, аренда оборудования (CPE/STB/ONT).
  • Pricing Engine: Правила ценообразования, скидки, промо-акции, loyalty-программы, volume discounts.
  • Subscriptions: Активные услуги клиента (Entitlements), переходы между статусами.
  • Bundling: Комбинированные предложения (Internet + IPTV + Telephony) с общей скидкой.
• Логика: Здесь решается, что клиент купил и сколько это стоит.
• Важный принцип: параметры услуги (например, "скорость = 100") — часть продуктовой модели и должны быть переносимыми между BSS/OSS через контракт (event payload), а не "вычисляться на NAS".

Типы продуктов (по модели тарификации):

Маркетинговые механики (по аналогии с Hydra Billing):

• Промо-акции: Скидка X% на первые N месяцев, бесплатный пробный период.
• Loyalty Discounts: Автоматическая скидка при стаже абонента > 12 мес.
• Volume Discounts: Скидка при подключении нескольких услуг (cross-sell).
• Referral Program: Скидка за привлечение нового абонента.
• Seasonal Offers: Временные тарифы (лето/каникулы) с auto-expire.

Жизненный цикл подписки:

ConnectRPC API (основные методы):

События (Exchange: isp.events.product): subscription.activated, subscription.suspended, subscription.terminated, subscription.tariff_changed.

3. Billing & Finance Service

Финансовое сердце платформы. Реализует полный цикл Revenue Management — от тарификации до reconciliation с банками.

• Объединяет функции:
  • Ledger: Балансы, транзакции, двойная запись (double-entry bookkeeping).
  • Rating Engine: Расчёт стоимости с учётом тарифа, скидок, proration (пропорциональное списание при смене тарифа в середине периода).
  • Billing Cycles: Рекуррентные списания (prepaid/postpaid), поддержка разных billing dates.
  • Invoicing: Генерация счетов, актов и УПД (для юрлиц), интеграция с 1С.
  • Payments: Интеграция с платежными шлюзами (Сбербанк, Тинькофф, ЮKassa, наличные, терминалы).
  • Dunning: Многоступенчатая работа с задолженностью и финансовые блокировки.
  • Autopay: Автоматическое списание с привязанной карты (recurring payments через токенизацию).
• Интеграция: При уходе в минус отправляет команды access.suspend/access.resume в RabbitMQ для OSS.
• Outbox: Все исходящие события публикуются через outbox-паттерн для гарантии доставки.

Модели тарификации:

Proration (пропорциональный расчёт):

При смене тарифа в середине биллингового периода:

• Старый тариф: Возврат за неиспользованные дни (credit adjustment)
• Новый тариф: Списание за оставшиеся дни (prorated charge)
• Формула: daily_rate = monthly_price / days_in_month, charge = daily_rate × remaining_days

Dunning pipeline (автоматический, конфигурируемый):

Настраиваемые параметры Dunning (по аналогии с Splynx/Hydra):

ConnectRPC API (основные методы):

События (Exchange: isp.events.billing): payment.received, balance.negative, invoice.issued, dunning.stage_changed. Команды (Exchange: isp.commands.provisioning): access.suspend, access.resume.

4. Notification Service

Универсальный шлюз уведомлений. Подписывается на события из всех доменов и доставляет уведомления клиентам/операторам.

• Каналы: SMS (SMPP/HTTP), Email (SMTP), Push (FCM/APNs), Telegram Bot, Webhook.
• Шаблоны: Шаблонизация через Handlebars / Nunjucks с переменными из event payload.
• Приоритеты: critical (мгновенно) → high (< 1 мин) → normal (< 5 мин) → low (batch, 1 раз в час).
• Дедупликация: По (customer_id, template_id, event_id) — защита от повторных уведомлений.
• Throttling: Не более N SMS в час на одного клиента (anti-spam).

Подписки на события:

---

Ссылки по теме

• Микросервисы: Каждый BSS-сервис подробно — Customer Core, Product, Billing, Notification.
• Доменные модели: ER-диаграммы, события, Context Map, Data Ownership — Доменная логика.
• Бизнес-процессы: Workflow'ы с участием BSS и OMS — Бизнес-сценарии (Workflows).
• API: Protobuf-контракты, ConnectRPC, RabbitMQ exchanges — API-контракты.
• Legacy маппинг: Как book_orders декомпозируется в BSS-сервисы — Маппинг Legacy CRM.
• Метрики: ARPU, churn, платежи, dunning pipeline — Observability.
• Безопасность: Keycloak RBAC, аудит финансовых операций — Безопасность.
• Принципы: Aggregate Root, Value Object, UoW — Принципы архитектуры.