Deneyim Özeti

Kendi oluşturduğum CMS platformu için üyelik aboneliği kısmı her zaman "uygulanması kolay" olmuştur. Bu hafta sonu bu kısmı yeniden yapılandırdım ve ana kısmı geliştirdim.

1. Yöntem

Genel olarak üyelik aboneliği temel olarak üç bölümden oluşur: üyelik abonelik planı ve satın alma, üye izin kontrolü ve üye yönetimi.

1. Üyelik abonelik planları ve satın alımlar için

Mevcut alışveriş merkezi sistemine dayalı olarak bazı genişletmeler yapmaya hazırlanın.

2. Üye izin kontrolü için,

Bunu özellikle belirtmek gerekiyor, bunu rol izin sistemi üzerinden değil, üye kontrollü ayrı bir sistem üzerinden yapmayı planlıyoruz.

Rol yetki sistemine göre üyeler bir rol dizisine dönüştürülür ve her üye türü bu rol dizisinde bir rol haline getirilir. Kulağa makul geliyor. Ancak bu durumda yapılması veya kullanılması oldukça zahmetlidir, özellikle iş çok olduğunda çeşitli mantıklar çok karmaşık hale gelecek ve dikkatli olunmadığı takdirde her türlü kafa karışıklığına neden olacaktır. Ve yeterince esnek değil.

Üstelik pek çok mükemmel sistemin üyelik aboneliği kısmı aslında rol bazlı değil. Bunun yerine izin kontrolü "işaretlere" veya emirlere göre uygulanır. WordPress dahil pek çok çok satan üyelik aboneliği eklentisi bu şekilde yapılır.

"Kullanıcı etiketleri" temel alınarak:

Özünde karakter sistemiyle aynı prensiptir. Üyelerin bazı "markalarını" tanımlamaktır.Bu "marka"ya bağlı üyelik abonelik planını satın alan kullanıcılar "bu işaretle işaretlenecek", böylece üye izinlerinin kontrolü sağlanabilecektir.

Siparişe göre:

Üyelik abonelik planı satın alın ve sipariş oluşturun.Ödeme yapıldıktan sonra son kullanma tarihi siparişe yazılacaktır. Dolayısıyla kullanıcının üye olup olmadığına, ne tür bir üye olduğuna, süresinin dolup dolmadığına göre sıralamaya göre karar verebilirsiniz. Bu şekilde üye izinlerini kontrol edebilirsiniz.

Daha önce sıra bazlı bir yöntem yapmıştım bu sefer "kullanıcı etiketleri" kullanmayı planlıyorum.

Siparişlere dayalı olmanın yanlış bir yanı yok, ancak oluşturduğum CMS platformunun sipariş sistemi şu anda birçok sipariş türünü destekliyor, bu da sipariş modelini nispeten "büyük" hale getiriyor.Artık buna "ağırlık eklemeyi" planlamıyorum, bu yüzden "kullanıcı etiketlerine" dayalı olarak seçtim.

3. Üye yönetimi

Mevcut kullanıcı yönetimi eklentisini baz alarak üye yönetimini tek başına yapmayı planlamıyoruz.

2. Uygulanabilir senaryolar

1. Temel senaryo

Ürünün tamamı, kullanıcıların satın aldığı ve üyelik hizmetlerinden yararlandığı bir veya daha fazla abonelik planına sahiptir.

Üyelik etiketlerini genel olarak tanımlayın. Her üyelik etiketi en az üç alan içerir: ad, bilgi ve ilgili abonelik planı kimliği.

Bir kullanıcı üyelik işaretli bir abonelik planı satın aldığında, üyelik işareti ve son kullanma tarihi kullanıcının meta verilerine yazılacaktır.

2. Platform/çok kiracılı senaryo

Platformlar ve çok kiracılı SAAS için çok önemli bir senaryo var: Satıcının kendisi tarafından sağlanan abonelik planı.

Tedarikçinin kullanıcı meta verisinde tedarikçinin üyelik etiketini tanımlayın.Tedarikçinin üyelik etiketinin anahtarı, global üyelik etiketinin anahtarı ile aynı olamaz.

Bir kullanıcı bu sağlayıcıdan bir abonelik planı satın aldığında, ilgili üyelik etiketi ve son kullanma tarihi, satın alan kullanıcının meta verilerine yazılacaktır.

Bu yineleme yalnızca temel senaryoları uygular ancak platform ve çok kiracılı senaryolara genişletilebilmesi gerekir.

3. Giriş yaparken üyeliğin süresinin dolup dolmadığını belirleyin

Kullanıcı giriş yaptığında süresinin dolup dolmadığına bakılır, eğer süresi dolmuşsa meta verideki üye işaretini false, son kullanma tarihini ise false olarak güncelleyin.