Направление работ: Back
Код раздела: 8.3.4 Администрирование > Тарифы > Подписки
Статус: Готов
Ответственный: Панкова Л.А.
Версия: 0.1
Обновлено: 19.08.26
1. Назначение
Подписки (Клиентские тарифы) предназначены для обеспечения доступа к возможностям сервиса в качестве клиента.
Подписка служит источником базовых прав — доступного функционала, лимитов по Заказам и условий кэшбека — и дополнительных прав при расширении Клиентской зоны доступа.
2. Ключевые понятия
Тариф — сущность, которая отвечает за процессы, связанные с реализацией услуг сервиса и возможностями системы для конкретного пользователя.
Подписка (Клиентский тариф) — Тариф, предназначенный для обеспечения доступа к возможностям сервиса в качестве клиента.
Базовый тариф — Подписка, которая бессрочно активируется для всех Карточек клиентов и служит источником базовых прав; Базовый тариф может быть только один.
Расширенный тариф — Подписка, которая предоставляет дополнительные права при расширении Клиентской зоны доступа; количество Расширенных тарифов не ограничено.
Условие кэшбека по Заказам — связанное с Подпиской условие начисления клиенту кэшбека за закрытые Заказы во время действия Тарифа.
3. Scope
Входит
S1 Подписка: назначение, базовые и дополнительные права, количество Базовых и Расширенных тарифов.
S2 Доступность и активация: Базовый тариф, срок действия, ограничения активаций и будущая доступность для выбранных клиентов и групп.
S3 Расчетные параметры: периоды, скидка, автопродление, стоимость и кэшбек за покупку Тарифа.
S4 Условия кэшбека по Заказам: область действия и размер начисления.
S5 Лимиты по активным резервам: область действия, количество и сумма Заказов.
S6 Доступный функционал: базовые права и дополнительные права при расширении Клиентской зоны доступа.
Не входит
- Back: 8.3 Тарифы
- Back: 1.3.1 Клиентская зона доступа
- Back: 1.3.4 Расширение клиентских прав доступа через подписки
- Back: 5.5 Провайдеры онлайн оплат
- Back: 8.4.2 Настройки балльной системы
- Back: 8.2.1 Сферы и Опции
- Back: 8.2.3 Гео-справочники — Города и Общественный транспорт
- Back: 8.2.2 Интерфейсы и Источники
4. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе.
| ID | Требование | Комментарий | Тип требования | Вес | Статус |
|---|---|---|---|---|---|
| S1: BR8.3.4-1 | Подписка предназначена для обеспечения доступа к возможностям сервиса в качестве клиента | Клиентские возможности: раскрываются в Back: 1.3.1 Клиентская зона доступа | Бизнес | 1 | Реализовано |
| S1: BR8.3.4-2 | Подписка служит источником базовых и дополнительных клиентских прав | Базовые права: доступный функционал, лимиты по Заказам и условия кэшбека. Дополнительные права: предоставляются при расширении Клиентской зоны доступа. Количество Тарифов: Базовый тариф может быть только один; количество Расширенных тарифов не ограничено | Бизнес | 1 | Частично OQ8.3.4-2 |
| S2: BR8.3.4-3 | Подписка должна хранить основные параметры | Состав данных: - Название Тарифа — краткое наименование - Описание Тарифа — подробное описание - Срок действия Тарифа — период доступности для использования: дата и время начала — дата и время окончания | Системное | 1 | Частично OQ8.3.4-1 |
| S2: BR8.3.4-4 | Подписка должна поддерживать ограничение доступности для выбранных клиентов и групп клиентов (после релиза реализация) | Параметры доступности: - Разрешенные клиенты — множественный выбор Карточек клиентов, у которых Тариф отображается как доступный - Разрешенные группы клиентов — множественный выбор клиентских групп, у которых Тариф отображается как доступный | Системное | 3 | Не реализовано |
| S2: BR8.3.4-5 | Базовый тариф должен бессрочно активироваться для всех Карточек клиентов и иметь стоимость 0 рублей | Параметр Базовый: может быть установлен только у одного Тарифа.Ограничения: - Тариф с этим параметром нельзя архивировать или удалить - по этому Тарифу система определяет параметры Базового тарифа - присвоить параметр Базовый другому Тарифу невозможно | Системное | 1 | Частично OQ8.3.4-2 |
| S2: BR8.3.4-6 | Подписка должна ограничивать количество и повторность активаций | Количество активаций: задается целым числом и обозначает лимит использования по всем пользователям. В интерфейсах такой Тариф помечается как ограниченное предложение. Флаг одноразового использования: задает одноразовое предложение или триал-период. При установленном флаге Тариф можно активировать только один раз на клиента | Системное | 1 | Частично OQ8.3.4-1 |
| S3: BR8.3.4-7 | Подписка должна задавать расчетный период и ограничение на суммарное количество приобретаемых периодов | Тип расчетного периода (дни/месяц): количество дней или месяцев, которое выбирает пользователь для оплаты. - Расчет месяца: с даты и времени активации Тарифа по такую же дату и время следующего месяца. Пример: оплата произведена 7 апреля 15:48, Тариф будет действовать по 7 мая 15:48. Значение периода (число): количество дней или месяцев, которые определяют один период. - Ограничение по максимальному значению: дней — 365, месяцев — 12. Количество доступных периодов для оплаты: ограничение на суммарное количество приобретаемых периодов. - Пример: ограничение установлено на 12 месяцев. Если оплачено 10 месяцев, активировать можно еще на 2 | Системное | 1 | Частично OQ8.3.4-1 |
| S3: BR8.3.4-8 | Подписка должна поддерживать скидку за периоды, автопродление и фиксированную стоимость периода | Скидка в % за каждый период: рассчитывается по формуле Сумма по тарифу = (количество периодов - 1) * размер скидки.Автопродление: флаг автоматической пролонгации по истечении срока доступа через Back: 5.5 Провайдеры онлайн оплат. Стоимость в рублях за период: фиксированная стоимость условия за период, включая 0 рублей | Системное | 1 | Частично OQ8.3.4-1 |
| S3: BR8.3.4-9 | Подписка должна поддерживать кэшбек за покупку Тарифа в процентах | Размер кэшбека: значение кэшбека баллами за оплату Тарифа определяется по Back: 8.4.2 Настройки балльной системы | Бизнес | 1 | Частично OQ8.3.4-1 |
| S4: BR8.3.4-10 | Подписка должна хранить Условия кэшбека по Заказам | Назначение: список привязанных условий начисления кэшбека. Состав каждого условия: - Название условия — текстовое название - Сфера — множественный выбор сфер, в которых действует начисление кэшбека за Заказы, с проверкой по Объекту создания Заказа; значения берутся из Back: 8.2.1 Сферы и Опции - Город — множественный выбор городов, в которых действует начисление кэшбека, с проверкой по Объекту создания Заказа; значения берутся из Back: 8.2.3 Гео-справочники — Города и Общественный транспорт - Источники — множественный выбор источников Заказа, по которым действует начисление кэшбека; значения берутся из Back: 8.2.2 Интерфейсы и Источники - Размер кэшбека за Заказы — процент, начисляемый клиенту за закрытые Заказы во время активности Тарифа по Back: 8.4.2 Настройки балльной системы | Системное | 1 | Частично OQ8.3.4-1 |
| S5: BR8.3.4-11 | Подписка должна хранить Лимиты по активным резервам | Состав каждого лимита: - Название лимита — текстовое название - Сферы — множественный выбор сфер, по которым действует лимит, из Back: 8.2.1 Сферы и Опции - Источники — множественный выбор источников Заказа, по которым действует лимит, из Back: 8.2.2 Интерфейсы и Источники - Количество Заказов — количество Заказов, на которые действует лимит - Сумма Заказов — сумма Заказов, на которую действует лимит в каждой Партнерской зоне | Системное | 1 | Частично OQ8.3.4-1 |
| S6: BR8.3.4-12 | Подписка должна хранить Доступный функционал для работы в мобильном приложении | Доступный функционал: список разрешений, которые предполагает активация Тарифа. Состав и иерархия прав: - Базовые права — права из Back: 1.3.1 Клиентская зона доступа - Расширение клиентских прав доступа через Подписки — вложенная группа дополнительных прав из Back: 1.3.4; состав группы раскрывается в BR8.3.4-13 | Системное | 1 | Не реализовано OQ8.3.4-3 |
| S6: BR8.3.4-13 | Подписка должна предоставлять дополнительные права при расширении Клиентской зоны доступа (после релиза реализация) | Расположение: дополнительные права являются вложенной группой параметра Доступный функционал и относятся к Back: 1.3.4 Расширение клиентских прав доступа через Подписки. Состав вложенной группы: - Подписка на занятое время — клиент может оставить заявку на уведомление об освобождении занятой Площадки для выбранной даты и интервала времени - Лояльные правила отмены — доступ к лояльным правилам отмены партнеров - Групповые Заказы — доступ к созданию групповых Заказов - Группы клиентов — доступ к созданию и управлению группами клиентов | Бизнес | 3 | Не реализовано |
5. Открытые вопросы
Первая полная сверка (дейлики сентябрь 2026): BRD 8.3.4 v0.1 · репозиторий
booking-monorepo· commit82359296/main· 2026-09-08 · якорьsrc/services/booking.clients(Clients.Domain/Aggregates/ClientTariffAggregate,ClientTariffPurchaseAggregate,Clients.Application/Commands/ClientTariffs*). Гайдбук на вход не передавался — маршрутизация без сверки с гайдбуком. Сводка: 3 вопроса (Open 3 · все — Разработке). Из 13 требований 2 подтверждены живым кодом без оговорок (BR8.3.4-1, автоматическое назначение Базового тарифа при регистрации клиента), 8 получили статус «Частично» — модель и бизнес-правила в коде корректны (включая формулу скидки за периоды и лимиты активаций — см. OQ8.3.4-1), но CRUD-ручки Подписок помечены в коде как неиспользуемые; 3 требования (BR8.3.4-4, BR8.3.4-12, BR8.3.4-13) не реализованы — для двух из них это ожидаемо и явно помечено в самом BRD как «после релиза реализация».
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ8.3.4-1 | Код BR8.3.4-3, BR8.3.4-6, BR8.3.4-7, BR8.3.4-8, BR8.3.4-9, BR8.3.4-10, BR8.3.4-11 | Требование говорит: Подписка должна хранить название/описание/срок действия, ограничивать активации по количеству и одноразовости, задавать расчётный период (макс. 365 дней/12 месяцев) со скидкой и автопродлением, кэшбек за покупку, Условия кэшбека по Заказам (сфера/город/источники/процент) и Лимиты по активным резервам (сферы/источники/кол-во заказов/сумма заказов). В коде всё это реализовано точно и с проверками: ClientTariffAggregate хранит все перечисленные поля, Period.SetQuantity жёстко проверяет лимит «дни ≤ 365, месяцы ≤ 12» — дословное совпадение с BR8.3.4-7, CashbackCondition и LimitRule — поле-в-поле совпадение с составом BR8.3.4-10 и BR8.3.4-11, а CreateClientTariffPurchaseHandler реальным кодом проверяет лимит активаций, одноразовость на клиента, суммарное количество периодов и считает скидку по формуле (периоды − 1) × скидка, дословно совпадающей с BR8.3.4-8. Но сами команды создания/изменения Подписки и покупки Подписки помечены как неиспользуемые, и по автосгенерированному словарю API ни одно клиентское приложение их не вызывает (кроме одного read-метода истории подписок клиента, который использует сервисный кабинет). Создать/изменить Подписку или купить её для клиента через существующие интерфейсы сейчас нельзя. \ ClientTariffAggregate.cs:10-25; Clients.Domain/Aggregates/ClientTariffAggregate/ValueObjects/Period.cs:24-30 (лимит 365/12); ValueObjects/CashbackCondition.cs:5-33; ValueObjects/LimitRule.cs:5-34; CreateClientTariffPurchaseHandler.cs:38-104 (лимиты, одноразовость, формула скидки); CreateClientTariffCommand.cs:10 [Obsolete("unused")]; UpdateClientTariffCommand.cs:10 [Obsolete("unused")]; CreateClientTariffPurchaseCommand.cs:9 [Obsolete("unused")]; Musbooking.ApiGateway/ApiDocs/api-dictionary.json:9111-9120 (CreateClientTariffService, deprecated: true, obsoleteInCode: true), :9914-9923 (UpdateClientTariffService), :9104-9110 (CreateClientTariffPurchaseService); контрпример — :9468-9477 (GetClientTariffByClientService, deprecated: false, используется сервисным кабинетом) | Разработка | Open | Подтвердить план подключения AdmLk/WebLk/Mobile к CRUD Подписок (работа Ксении, июль 2026) — бизнес-логика полностью готова и проверена, не хватает только вызывающей стороны. Если интеграция не в ближайших планах — явно отразить это в статусе раздела вместо «Реализовано». | |
| OQ8.3.4-2 | Код BR8.3.4-2, BR8.3.4-5 | Требование говорит: Базовый тариф может быть только один, он бессрочно активируется для всех Карточек клиентов, имеет стоимость 0 рублей, его нельзя архивировать/удалить, и присвоить признак «Базовый» другому Тарифу невозможно. В коде часть требования подтверждена реальным работающим кодом: DefaultClientTariffAssignmentService.EnsureAssignedAsync вызывается при регистрации/создании клиента и присоединении аккаунта и автоматически выдаёт клиенту покупку Базового тарифа с pricePaid = 0 и датой окончания DateTime.MaxValue, если у Тарифа не задан период — то есть «бессрочно и 0 рублей» для автоназначения работает. Но защитных проверок вокруг самого признака IsDefault не найдено: CreateClientTariffHandler/UpdateClientTariffHandler не проверяют, что Тариф с IsDefault = true уже существует (можно создать несколько), UpdateClientTariffHandler позволяет заархивировать Тариф с IsDefault = true без ограничений, а DeleteClientTariffHandler удаляет любой Тариф, включая Базовый, без проверки. \ DefaultClientTariffAssignmentService.cs:25-77 (автоназначение, бессрочность, 0 руб.); вызовы — CreateClientCommandHandler.cs:45,80, ApplyRegistrationDataToClientCommandHandler.cs:57, AttachAccountToClientCommandHandler.cs:53; CreateClientTariffHandler.cs:20-62 и UpdateClientTariffHandler.cs:18-53 — проверки IsDefault-уникальности нет; DeleteClientTariffHandler.cs:17-31 — проверки на IsDefault нет | Разработка | Open | Завести задачу на защиту инварианта Базового тарифа: запретить создание второго IsDefault = true, запретить архивацию/удаление Тарифа с IsDefault = true (или снятие признака без явного переноса на другой Тариф) на уровне хендлеров. | |
| OQ8.3.4-3 | Код BR8.3.4-12 | Требование говорит: Подписка должна хранить «Доступный функционал» — список базовых прав (из 1.3.1) и вложенную группу дополнительных прав при расширении доступа (BR8.3.4-13). В коде на ClientTariffAggregate и в связанных persistence-моделях нет ни одного поля, относящегося к правам/разрешениям/функционалу — только коммерческие параметры (период, скидка, кэшбек, лимиты по заказам). В отличие от дочернего требования BR8.3.4-13, само BR8.3.4-12 не помечено в BRD пометкой «после релиза реализация», поэтому расхождение зафиксировано отдельным вопросом, а не как ожидаемый пробел. \ ClientTariffAggregate.cs:10-38 (полный список полей агрегата — прав/функционала нет); поиск Permission/Feature/Right по Clients.Domain/Aggregates/ClientTariffAggregate — совпадений нет | Разработка | Open | Уточнить, планируется ли хранение «Доступного функционала» до релиза BR8.3.4-13 отдельно от него, или оба требования (BR8.3.4-12 и -13) считаются одним пакетом «после релиза» — тогда стоит унифицировать пометку в BRD. |