Итерация модуля подписки на членство
Для платформы CMS, которую я создал сам, часть подписки на членство всегда была «простой в реализации». На этих выходных я реструктуризировал эту часть и разработал основную часть.
1. Метод
Вообще говоря, членская подписка в основном состоит из трех частей: план и покупка членской подписки, контроль разрешений участников и управление участниками.
1. Для планов членской подписки и покупок
Просто приготовьтесь сделать некоторые расширения на основе существующей системы торгового центра.
2. Для контроля разрешений участников:
Об этом следует упомянуть особо: мы планируем делать это не на основе ролевой системы разрешений, а на основе отдельной системы, контролируемой участниками.
В зависимости от ролевой системы полномочий участники объединяются в серию ролей, и каждый тип участников превращается в роль в этой серии ролей. Это звучит разумно. Однако в этом случае это очень сложно делать или использовать, особенно когда дел много, различная логика будет очень сложной, и если вы не будете осторожны, возникнет всевозможная путаница. И он недостаточно гибок.
Более того, на самом деле членская подписная часть многих отличных систем не основана на ролях. Вместо этого контроль разрешений реализуется на основе «отметок» или приказов. Многие хорошо продаваемые плагины членской подписки, включая WordPress, созданы таким образом.
На основе «тегов пользователя»:
По сути, это тот же принцип, что и система персонажей. Это необходимо для определения некоторых «отметок» участников. Пользователи, которые приобретают план подписки, связанный с этой «отметкой», будут «отмечены этой отметкой», чтобы можно было обеспечить контроль разрешений участников.
На основании заказа:
Приобретите тарифный план членства и сформируйте заказ.После оплаты в заказ будет записан срок его действия. Таким образом, на основе порядка вы можете судить, является ли пользователь участником, какого он типа и истек ли срок его действия. Таким образом, вы можете контролировать разрешения участников.
Раньше я использовал метод на основе порядка, и на этот раз планирую использовать «пользовательские теги».
Нет ничего плохого в том, чтобы основываться на заказах, но система заказов платформы CMS, которую я сейчас создаю, поддерживает множество типов заказов, что делает модель заказов относительно "большой". Я больше не планирую "добавлять к ней вес", поэтому я выбрал на основе «тегов пользователя».
3. Управление участниками
Учитывая существующее расширение управления пользователями, мы не планируем осуществлять управление участниками в одиночку.
2. Применимые сценарии
1. Базовый сценарий
Весь продукт имеет один или несколько планов подписки, которые пользователи приобретают и пользуются членскими услугами.
Определите теги членства глобально. Каждый тег членства содержит как минимум три поля: имя, ярлык и связанный идентификатор плана подписки.
Когда пользователь приобретает план подписки со знаком членства, знак членства и срок действия будут записаны в метаданные пользователя.
2. Сценарий платформы/мультиарендатора
Для платформ и мультитенантных SAAS есть очень важный сценарий: план подписки, предоставляемый самим поставщиком.
Определите тег членства поставщика в метаданных пользователя поставщика. Ключ тега членства поставщика не может совпадать с ключом глобального тега членства.
Когда пользователь приобретает план подписки у этого поставщика, соответствующий тег членства и дата истечения срока действия будут записаны в метаданные приобретающего пользователя.
Эта итерация реализует только базовые сценарии, но ее необходимо расширить до платформенных и многопользовательских сценариев.
3. Определите, истек ли срок действия членства при входе в систему.
Когда пользователь входит в систему, оценивается, истек ли срок его действия. Если срок его действия истек, обновите отметку участника в метаданных на ложь, а дату истечения срока действия на ложь.
