В веб-сервисе есть регулируемые ресурсы. Их наличие/отсутствие/величина – то, за что берут оплату. Можно купить отдельную фишку, или проподнять отдельный параметр на какое-то время. Можно купить «тарифный план», включающий набор продвинутых параметров и действующий месяц.
Вопрос: как лучше описать / управлять этими ресурсами в рамках приложения? Вероятно, для разработчиков игр, хостинга или операторов мобильной связи тема избитая и давно решённая.
Интересно услышать мнение реализовавших что-то подобное в своих проектах.
Сложности возникли при учёте коллизий. Напр., купил тариф T.A, в котором параметр P1 поднимается до 100. Этот T.A действует 1 календарный месяц. Но пользователь взял, и через две недели купил отдельный апгрейд P1 до 200, сроком на 2 недели.
Для некоторых параметров возможно сложение: т.е. на две недели у пользователя будет P1 = 100+200 = 300. Для некоторых сложение невозможно, и нужно последовательно держать P1 = 200, а по истечении апгрейда продолжить на уровне тарифа P1 = 100. И ещё вопрос, продлить ли это на 2 недели, или отключить, как только пройдёт месяц действия тарифа? (По-честному, надо продлить, пожалуй.)
Система растёт, и будут появляться новые «предметы для торга» и новая бизнес-логика. Как более-ли-менее разумно заранее предусмотреть возможные усложнения маркетинга?
Пока каждый Параметр заносится в БД, вместе с описанием его свойств: добавляется или последователен, и т.п. При покупке пользователь приобретает Товар, который состоит из одного или нескольких Параметров, и имеет срок действия. И купленные Параметры заносятся в таблицу Активаций: сегодня со знаком плюс, и по окончании действия, с минусом. При появлении для одного Пользователя нескольких одинаковых Параметров, их даты корректируются.
Вам стоит изучить вопрос учета договоров в страховом бизнесе. Судя по условиям, которые Вы описали - на вскидку...
Но лучше, максимально упрощать концепт-модель, так как её все равно придется оптимизировать.
Простой
Средний
