Erfarenhetssammanfattning

För plattformen CMS jag byggt själv har medlemsprenumerationsdelen alltid varit "enkel att implementera". I helgen strukturerade jag om den här delen och utvecklade kärndelen.

1. Metod

Generellt sett inkluderar medlemskapsprenumerationen huvudsakligen tre delar: medlemskapsprenumerationsplan och -köp, medlemsbehörighetskontroll och medlemshantering.

1. För medlemsprenumerationsplaner och köp

Förbered dig bara på att göra några tillägg baserat på det befintliga köpcentrets system.

2. För medlemsbehörighetskontroll,

Detta behöver nämnas särskilt. Vi planerar inte att göra det utifrån ett rollbehörighetssystem, utan ett separat medlemskontrollerat system.

Utifrån rollbefogenhetssystemet görs medlemmar till en rollserie och varje typ av medlem görs till en roll i denna rollserie. Det låter rimligt. Men i det här fallet är det väldigt besvärligt att göra eller använda, speciellt när det är mycket affärer, de olika logikerna kommer att vara mycket komplicerade och alla typer av förvirring kommer att uppstå om du inte är försiktig. Och det är inte tillräckligt flexibelt.

Dessutom är medlemsprenumerationsdelen av många utmärkta system faktiskt inte rollbaserad. Istället implementeras behörighetskontroll baserat på "märken" eller order. Många välsäljande plugin-program för medlemskapsabonnemang, inklusive WordPress, görs på detta sätt.

Baserat på "användartaggar":

I huvudsak är det samma princip som karaktärssystemet. Det är för att definiera några "märken" för medlemmar. Användare som köper medlemskapsabonnemangsplanen som är kopplade till detta "märke" kommer att "märkas med detta märke", så att kontrollen av medlemsbehörigheter kan uppnås.

Baserat på beställning:

Köp en medlemsprenumerationsplan och gör en beställning Efter betalning kommer utgångstiden att skrivas in i beställningen. Därför kan du utifrån ordningen bedöma om användaren är medlem, vilken typ av medlem det är och om den har gått ut. På så sätt kan du kontrollera medlemsbehörigheter.

Jag har gjort en orderbaserad metod tidigare, och den här gången planerar jag att använda "användartaggar".

Det är inget fel med att vara baserad på beställningar, men beställningssystemet för plattformen CMS jag bygger nu stödjer många beställningstyper, vilket gör att beställningsmodellen är relativt "stor, jag planerar inte att "lägga till vikt" till den längre. så jag valde Baserat på "användartaggar".

3. Medlemshantering

Baserat på den befintliga användarhanteringstillägget planerar vi inte att göra medlemshantering ensam.

2. Tillämpliga scenarier

1. Grundscenario

Hela produkten har en eller flera prenumerationsplaner, som användare köper och njuter av medlemstjänster.

Definiera medlemskapstaggar globalt Varje medlemskapstagg innehåller minst tre fält: namn, slug och tillhörande prenumerationsplan-id.

När en användare köper en prenumerationsplan med ett medlemsmärke, kommer medlemsmärket och utgångstiden att skrivas in i användarens metadata.

2. Scenario för plattform/flerhyresgäst

För plattformar och SAAS med flera hyresgäster finns det ett mycket viktigt scenario: prenumerationsplanen som tillhandahålls av leverantören själv.

Definiera leverantörens medlemstagg i leverantörens användares metadata. Nyckeln till leverantörens medlemstagg kan inte vara densamma som nyckeln för den globala medlemstaggen.

När en användare köper en prenumerationsplan från den här leverantören kommer motsvarande medlemskapstagg och utgångsdatum att skrivas till den köpande användarens metadata.

Denna iteration implementerar bara grundläggande scenarier, men den måste kunna utvidgas till plattforms- och multi-tenant-scenarier.

3. Ta reda på om medlemskapet har gått ut när du loggar in

När användaren loggar in bedöms det om det har gått ut. Om det har gått ut, uppdatera medlemsmärket i metadatan till falskt och utgångsdatumet till falskt.