Заявление об авторских правах: эта статья является оригинальной статьей блоггера и не может быть воспроизведена без разрешения блоггера. Подпишитесь на официальный аккаунт Techhui (ID: jishuhui_2015), чтобы связаться с автором.
Суть купонной системы заключается в управлении, выдаче и использовании различных купонов.
Обычный угол дизайна исходит от конечного пользователя, так называемое «что видишь, то и получаешь», различные купоны, которые видит конечный пользователь, как раз и являются проблемой разработки всей системы.
Вполне возможно, что для взаимодействия с различными формами онлайн- и офлайн-деятельности купонная система должна претерпеть серьезные изменения, и главной проблемой стало минимизация затрат на эти изменения.
Что касается вышеупомянутых проблем, решение состоит в том, чтобы изолировать правила от выполнения.
Слой правил относится к ограничениям на использование различных купонов и эффектам, которые могут быть достигнуты.
Уровень исполнения можно понимать как вычисление конечной цены сделки в соответствии с правилами.
Что касается слоя правил, то автор не хочет поднимать его до уровня механизма правил, а только сделать соответствующую абстракцию. Более того, существующая на рынке структура разработки механизма правил может не соответствовать сложному сценарию применения купонов.
Стоит отметить, что купоны не приравниваются к каким-либо льготным акциям, а являются частью общей системы маркетинга. По сравнению с купонами реализация системы поощрения еще сложнее. Цель этой статьи — объяснить, как разработать купонную систему, но разработка и реализация рекламных мероприятий выходят за рамки этой статьи.
1. Как генерировать купоны
Прежде чем генерировать купоны, давайте взглянем на "шаблон купона"Концепция чего-либо.
Как следует из названия, следуйте шаблону для создания купонов.
Точно так же, как пресс-форма на промышленной производственной линии, вам нужно только ввести сырье для обработки, чтобы получить готовый продукт.
Таким образом, шаблон содержит много информации, связанной с купоном, включая, помимо прочего, имя, своевременность, различные льготные правила, номинал купона и т. д. Сам шаблон также содержит основную информацию, такую как название, статус и создатель.
Когда вам нужно сгенерировать купоны, вы можете указать, какой набор шаблонов использовать, а затем указать общее количество купонов, которые должны быть сгенерированы.Вы также можете указать получателей в процессе создания купонов для завершения операции распространения купонов.
Может быть, читатели не могут не спросить: этот дизайн кажется немного избыточным. Существует много перекрывающихся атрибутов между шаблонами купонов и объектами купонов. Почему бы просто не пропустить ссылку на шаблоны купонов и не создать купоны напрямую?
Этому есть две причины:
Во-первых, вы не хотите повторно вводить одну и ту же информацию о купоне, достаточно один раз ввести информацию о шаблоне, чтобы генерировать купоны партиями, что может повысить эффективность работы операторов;
Во-вторых, создание шаблонов купонов и отправка объектов купонов выполняются людьми с двумя разными разрешениями. Операторы с более высокими полномочиями могут иметь право создавать шаблоны, в то время как обычным операторам нужно только выдавать купоны в соответствии с шаблоном.
Как показано на рисунке ниже, это может отражать взаимосвязь между шаблонами купонов и объектами купонов:
2. Разработка льготных правил
Содержание, представленное на картинке выше, в основном можно увидеть с первого взгляда.Далее мы сосредоточимся на разработке преимущественных правил.
Преференциальные правила, несомненно, являются ядром купонной системы, и от того, насколько хорошо будут реализованы преференциальные правила, зависит, смогут ли они адаптироваться к потребностям рыночных операций.
Очевидно, что использовать исчерпывающий метод для реализации льготных правил на рынке неразумно.
Поскольку так называемая «единственная константа в мире — это изменение», мы должны извлечь сущность преференциальных правил, чтобы «отвечать на все изменения тем же».
Автор провел исследование общих преференциальных правил на рынке, и в сочетании с потребностями собственного бизнеса преференциальные правила можно условно разделить на две категории:
1. Расчетные правила. В форме «без порога, прямо вниз 20 юаней», «полный хх минус хх» и т. д. эти правила выставляются конечным пользователям, что очевидно, чтобы пользователи знали, как этот купон участвует в расчете.
2. Ограничительные правила. По сравнению с вычислительными правилами ограничительные правила в основном неявны. Например: ограничение получения определенными пользователями, ограничение максимального количества купонов, которые может выдать определенный шаблон купона, ограничение каналов для купонов и т. д. Такие правила вполне могут поддерживать ежедневные операции.
«Все растет и подавляет друг друга», и многие льготные правила не могут все сосуществовать. Вот введение правила»взаимная исключительность"Концепция чего-либо. Когда предпочтительное правило и другое предпочтительное правило не могут существовать в наборе шаблонов одновременно, мы считаем эти два правила взаимоисключающими, что также необходимо учитывать при разработке правил.
Во-вторых, преференциальные правила также будут обращать внимание на порядок приоритета, поэтому он должен ввести преференциальное правило».приоритет』Атрибут, мы договорились, что чем меньше число, тем выше приоритет, то есть в порядке от меньшего к большему.
Полная таблица правил приведена ниже, с большим объемом информации, и автор сделает необходимые пояснения.
В таблице правил ограничение канала, ограничение объекта, ограничение количества и ограничение количества являются правилами с ограничениями, и приоритет находится впереди. В то же время также приведены описания параметров, описания правил, связи с шаблонами и правила взаимного исключения, которые понятны с первого взгляда.
Следующие правила вычитания и правила ограничения являются расчетными правилами, и они также являются высшим приоритетом купонов.
Автор фокусируется на объяснении «полной редукции лестницы» в правиле полной редукции. Обычно мы видим такую поговорку: каждые 100 юаней минус 10 юаней, смысл: 10 юаней минус 10 юаней, 200 минус 20 юаней и так далее, автор называет это правилом «полная лестница минус».
3. Дизайн номера предпочтительного правила
В таблице правил задействовано много чисел, и автор разработал набор правил генерации.
Номер правила имеет тип int.В языке программирования Java полная длина int составляет 32 бита, как показано на следующем рисунке:
1. Первый бит — это знаковый бит, который фиксируется равным 0, и случай, когда все 32 бита равны 0, не допускается, то есть положительное целое число;
2. Верхние 8 цифр — это номер группы правил.Теоретически допустимый диапазон значений составляет от 0 до 255. Однако фактическое бизнес-правило предполагает, что существует не более 15 групп предпочтительных правил.Количество каждой группы предпочтительных правил составляет кратно 10, диапазон равен 10. ~150;
3. 10-й и 11-й биты используются как запасные и не имеют практического применения и имеют фиксированное значение 00;
4. Средние 15 цифр хранят номер правила в группе правил. Допустимый диапазон составляет 0 ~ 32767, но фактическое бизнес-правило заключается в достижении цели взаимного исключения. Значения следующие (возьмите четырехзначный двоичный код Например):
0001
0010
0100
1000
Вывод: Исключая случай всех 0, тогда есть N битов, и есть N групп взаимоисключающих пар. Если рассматривать взаимное исключение внутри и вне группы, то возможных значений меньше;
5. Последние 6 бит хранят приоритет группы правил.Допустимый диапазон значений 0~63.Фактическое значение начинается с 1.Учитывая, что другие группы правил будут вставлены позже, две группы правил будут зарезервированы непосредственно в каждых двух уровень групп правил, первоначальный приоритет устанавливается равным 1, 4, 7, 10, 13, 16...;
6. В соответствии с приведенными выше правилами номера подробных правил в приведенной выше таблице могут быть сгенерированы в соответствии с установленными группами и приоритетами.
Ограничение канала 83888577
0 00001010 00 000000000100111 000001
Ограничение по типу пользователя 167775300
0 00010100 00 000000000110001 000100
Лимит именованных пользователей 167776900
0 00010100 00 000000001001010 000100
Ограничение общей суммы 251660487
0 00011110 00 000000000100011 000111
Ограничение количества единиц 251662535
0 00011110 00 000000001000011 000111
Общий лимит 335545290
0 00101000 00 000000000001111 001010
Персональные ограничения 335544778
0 00101000 00 000000000000111 001010
Прямой редуктор без порога 419430989
0 00110010 00 000000000001001 001101
Полный минус 419431565
0 00110010 00 000000000010010 001101
Скидка 419436813
0 00110010 00 000000001100100 001101
Правила укупорки 503323024
0 00111100 00 000000001100110 010000
В-четвертых, программирование системы купонов
Прежде чем приступить к программированию, мы должны понять три основных действия с купонами:
1. Менеджмент. Относится к созданию шаблонов купонов, настройке правил, закрытию и другим операциям. Конечно, при задании параметров правила для шаблона необходимо проверять рациональность параметров правила.
2. Распространение/получение. Автор объединил эти две операции, разница между ними в том, что нет привязки конечного пользователя, которую можно объединить на уровне интерфейса. Обычно здесь вступают в действие ограничительные правила, и когда запускается одно из этих двух действий, оба проверяются на соответствие ограничительным правилам перед созданием купонов.
3. Используйте. Это потратить купоны, и здесь будут играть роль правила расчета, в основном для того, чтобы судить, удовлетворены ли купоны или нет, а также для расчета суммы вычетов и освобождений.
Подводя итог, дизайн программы расширяется этими тремя действиями.
Давайте сначала создадим слой правил.
Согласно ряду правил, определенных в таблице правил, отражение в программе может принимать две формы:
Один из них заключается в использовании файла конфигурации (обычно XML), а затем программа анализирует его;
Другой способ — использовать классы enum (или другие формы классов) напрямую.
Первый вид развития немного сложнее, и если вы хотите быть более мощным, это потребует много усилий.
Определение и реализация предпочтительных правил заложены в программу заранее, и непрофессионалам не под силу изменить конфигурационный файл для достижения эффекта.
Поэтому, исходя из этого соображения, используется вторая реализация. Ниже приводится определение правила:
Линейки содержат пять важных свойств: номер правила (ruleNo), имя правила (ruleName), сортировка (sort), соответствующий объект класса модели и имя службы, реализующее определенный интерфейс.
Следующие три метода также более важны: напрямую найти соответствующее перечисление по номеру правила, определить, является ли оно вычислительным правилом, имеет ли правило несколько параметров, а связь между 1~* и шаблоном купона означает, что оно имеет несколько параметры.
Конечно, есть также все виды bean-компонентов, которые сохраняются в базе данных.Каждый bean-компонент наследует абстрактный класс, называемый SuperRule, и все атрибуты подклассов упоминаются в таблице правил. Класс модели в правителях исходит из этого. Так как правил много, ниже показано только SuperRule:
Поскольку правила делятся на две категории, можно естественным образом вывести две услуги, соответствующие вычислительным правилам и ограничительным правилам.
Последний — это проверка параметров правила, которое использует универсальный R и наследуется от SuperRule.
Пока что дизайн интерфейса включает в себя вышеупомянутые три операции, связанные с купонами, а это означает, что в случае появления нового правила могут быть реализованы не более трех вышеуказанных услуг (потому что могут быть как ограничительные правила, так и вычислительная правило), но в большинстве случаев вам нужно всего лишь реализовать две службы, а затем настроить это новое правило в Rulers. Что касается основных операций правил CRUD, то, пока вы наследуете AbstractCouponRuleService, вам не нужно тратить дополнительные усилия на их реализацию.
С таким количеством правил естественно нужна "Заводской класс』 Для планирования, например, для создания экземпляра Bean-компонента правила, создания экземпляра Service.
V. Резюме
Эта статья дает более полное и ясное описание купонной системы, от бизнес-дизайна до разработки программы.Если читателю просто нужно разработать купонную систему, эта статья будет хорошим справочником.