メンバーシップ サブスクリプション モジュールの反復
私が自分で構築したプラットフォーム CMS では、メンバーシップのサブスクリプション部分は常に「実装が簡単」でした。今週末、この部分を再構成し、コア部分を開発しました。
1.方法
一般に、メンバーシップのサブスクリプションには主に、メンバーシップのサブスクリプション プランと購入、メンバーの権限制御、メンバーの管理の 3 つの部分が含まれます。
1. 会員登録プランおよび購入について
既存のモールシステムに基づいていくつかの拡張機能を作成する準備をするだけです。
2. メンバーの権限制御については、
これは特に言及する必要がありますが、ロール許可制ではなく、別のメンバー管理制に基づいて行う予定です。
ロール権限体系に基づいてメンバーをロールシリーズ化し、そのロールシリーズ内で各種類のメンバーをロール化する。それは合理的だと思われます。ただし、この場合、実行または使用するのが非常に面倒で、特にビジネスが多い場合は、さまざまなロジックが非常に複雑になり、注意しないとさまざまな混乱が発生します。そして柔軟性も十分ではありません。
さらに、実際には、多くの優れたシステムのメンバーシップのサブスクリプション部分はロールベースではありません。代わりに、許可制御は「マーク」または命令に基づいて実装されます。 WordPress を含む、多くのよく売れているメンバーシップ サブスクリプション プラグインはこの方法で行われています。
「ユーザータグ」に基づいて:
本質的にはキャラクターシステムと同じ原理です。会員の何らかの「マーク」を定義するもので、この「マーク」に関連付けられた会員プランを購入したユーザーには「このマークが付けられる」こととなり、会員権限の制御が可能となります。
注文に基づいて:
メンバーシップ サブスクリプション プランを購入して注文すると、支払い後に有効期限が注文書に書き込まれます。そのため、会員であるかどうか、どのような会員であるか、有効期限が切れているかどうかなどの順番で判断することができます。これにより、メンバーの権限を制御できます。
以前は順序ベースの方法を行ったことがありますが、今回は「ユーザータグ」を使用する予定です。
注文に基づくことに問題はありませんが、現在構築しているプラットフォーム CMS の注文システムは多くの注文タイプをサポートしているため、注文モデルが比較的「大きく」なっています。これに「重みを追加」するつもりはもうありません。そこで「ユーザータグ」に基づくを選択しました。
3. 会員管理
既存のユーザー管理拡張機能をベースに、メンバー管理のみを行う予定はありません。
2. 適用可能なシナリオ
1. 基本シナリオ
製品全体に 1 つまたは複数のサブスクリプション プランがあり、ユーザーはこれを購入してメンバーシップ サービスを楽しみます。
メンバーシップ タグをグローバルに定義します。各メンバーシップ タグには、名前、スラッグ、および関連するサブスクリプション プラン ID という少なくとも 3 つのフィールドが含まれます。
ユーザーが会員マーク付きの定期購入プランを購入すると、会員マークと有効期限がユーザーのメタデータに書き込まれます。
2. プラットフォーム/マルチテナントのシナリオ
プラットフォームとマルチテナント SAAS の場合、ベンダー自体が提供するサブスクリプション プランという非常に重要なシナリオがあります。
サプライヤーのユーザーのメタデータでサプライヤーのメンバーシップ タグを定義します。サプライヤーのメンバーシップ タグのキーは、グローバル メンバーシップ タグのキーと同じであってはなりません。
ユーザーがこのプロバイダーからサブスクリプション プランを購入すると、対応するメンバーシップ タグと有効期限が、購入したユーザーのメタデータに書き込まれます。
この反復では基本的なシナリオのみを実装しますが、プラットフォームおよびマルチテナントのシナリオに拡張できる必要があります。
3. ログイン時にメンバーシップの有効期限が切れているかどうかを確認する
ユーザーがログインした際に有効期限が切れているかどうかを判定し、有効期限が切れている場合はメタデータの会員マークをfalse、有効期限をfalseに更新します。
