Itération du module d'abonnement aux adhésions
Pour la plateforme CMS que j'ai moi-même construite, la partie abonnement a toujours été "simple à mettre en œuvre". Ce week-end, j'ai restructuré cette partie et développé la partie centrale.
1. Méthode
De manière générale, l'abonnement comprend principalement trois parties : le plan d'abonnement et l'achat d'un abonnement, le contrôle des autorisations des membres et la gestion des membres.
1. Pour les plans d'abonnement et les achats
Préparez-vous simplement à réaliser quelques extensions basées sur le système de centre commercial existant.
2. Pour le contrôle des autorisations des membres,
Cela doit être particulièrement mentionné : nous n'envisageons pas de le faire sur la base d'un système d'autorisation de rôle, mais d'un système distinct contrôlé par les membres.
Sur la base du système d'autorité de rôle, les membres sont transformés en une série de rôles, et chaque type de membre est transformé en un rôle dans cette série de rôles. Cela semble raisonnable. Cependant, dans ce cas, c'est très gênant à faire ou à utiliser, surtout lorsqu'il y a beaucoup d'affaires, les différentes logiques seront très compliquées et toutes sortes de confusions seront provoquées si vous n'y faites pas attention. Et ce n'est pas assez flexible.
De plus, dans les faits, la partie abonnement de nombreux excellents systèmes n’est pas basée sur les rôles. Au lieu de cela, le contrôle des autorisations est mis en œuvre sur la base de « marques » ou d’ordres. De nombreux plug-ins d’abonnement très vendus, y compris WordPress, sont créés de cette manière.
Basé sur les "balises utilisateur" :
En substance, c'est le même principe que le système de personnages. Il s'agit de définir certaines « marques » des membres. Les utilisateurs qui achètent le plan d'abonnement associé à cette « marque » seront « marqués de cette marque », afin que le contrôle des autorisations des membres puisse être réalisé.
Selon la commande :
Achetez un plan d'abonnement et passez une commande. Après le paiement, le délai d'expiration sera inscrit dans la commande. Par conséquent, vous pouvez juger en fonction de l'ordre si l'utilisateur est membre, de quel type de membre il s'agit et s'il a expiré. De cette façon, vous pouvez contrôler les autorisations des membres.
J'ai déjà utilisé une méthode basée sur les commandes et cette fois, je prévois d'utiliser des "balises utilisateur".
Il n'y a rien de mal à être basé sur les commandes, mais le système de commande de la plateforme CMS que je construis prend désormais en charge de nombreux types de commande, ce qui rend le modèle de commande relativement "large". Je n'ai plus l'intention de lui "ajouter du poids", j'ai donc choisi Basé sur les "balises utilisateur".
3. Gestion des membres
Sur la base de l'extension de gestion des utilisateurs existante, nous ne prévoyons pas de gérer seuls les membres.
2. Scénarios applicables
1. Scénario de base
L'ensemble du produit dispose d'un ou plusieurs plans d'abonnement, que les utilisateurs achètent et bénéficient de services d'adhésion.
Définissez les balises d'adhésion globalement. Chaque balise d'adhésion contient au moins trois champs : nom, slug et identifiant du plan d'abonnement associé.
Lorsqu'un utilisateur achète un plan d'abonnement avec une marque d'adhésion, la marque d'adhésion et le délai d'expiration seront écrits dans les métadonnées de l'utilisateur.
2. Scénario plateforme/multi-tenant
Pour les plateformes et les SAAS multi-tenants, il existe un scénario très important : le plan d'abonnement fourni par le fournisseur lui-même.
Définissez la balise d'adhésion du fournisseur dans les métadonnées de l'utilisateur du fournisseur. La clé de la balise d'adhésion du fournisseur ne peut pas être la même que la clé de la balise d'adhésion globale.
Lorsqu'un utilisateur achète un plan d'abonnement auprès de ce fournisseur, l'étiquette d'adhésion et la date d'expiration correspondantes seront écrites dans les métadonnées de l'utilisateur acheteur.
Cette itération n’implémente que des scénarios de base, mais elle doit pouvoir être étendue aux scénarios plateforme et multi-tenant.
3. Déterminez si l'adhésion a expiré lors de la connexion
Lorsque l'utilisateur se connecte, il est jugé s'il a expiré. S'il a expiré, mettez à jour la marque de membre dans les métadonnées sur false et la date d'expiration sur false.
