Abonelikleri, bakiyeleri ve fiyatlandırma planı değişikliklerini işleme [kapalı]

Önsöz
Amacım, abonelikleri yönetmek için birden fazla proje için yeniden kullanılabilir kod oluşturmak (ve ayrıca github'da yayınlamak). Şerit ve yinelenen faturalandırma sağlayıcılarını biliyorum, ancak bu modülün amacı bu değil. Hesap bakiyesini, aboneliği yenilemek için kolay bildirimleri ve fiyat hesaplamalarını işlemek için bir sarıcı / yardımcı olmalıdır.

Sağlayıcılar veya destek olanakları yetersiz veya hiç desteklenmeyen veya çok pahalı (mikro ödemeler) nedeniyle yinelenen faturalandırmayı kullanamayacağınız ülkeler vardır. Ve yinelenen faturalandırma kullanmak istemeyen, ancak yıl sonunda faturalarını manuel olarak ödeyen / faturalarını ödeyen insanlar var. Bu yüzden lütfen paypal yinelenen faturalandırma, yinelenen veya benzer hizmetleri önermeyin.

Durum
Diyelim ki bir abonelik planına (ör. User) Abone olabilecek bir modeliniz var . Bu model, şu anda abone olduğu bir abonelik planının tanımlayıcısını depolayan bir alana sahiptir. Böylece, her plan değişikliğinde, değişiklik kaydedilir.

SubscriptionPlanChangesSöz konusu değişiklikleri kaydeden aşağıdaki alanları içeren bir model (örn. ) Vardır :

• subscriberabone modeliyle ilgili ( Userbu durumda)
• from_plan modelin değişiklikten önce sahip olduğu plan tanımlayıcısının tanımlanması
• to_plan modelin şimdi seçtiği plan tanımlayıcısını tanımlamak
• created_at değişikliği saklayan bir tarih-saat alanıdır
• valid_until gerçek abonelik geçerli olana kadar tarihi saklar
• paid_at aynı zamanda aboneliğin ödenip ödenmediğini (ve ne zaman) tanımlayan bir tarih-saat alanıdır

Tabii ki, bu düzen tartışılabilir.

Hesap bakiyesi
sorusu Bir kullanıcı abonelik planını değiştirdiğinde, plan alanlarını karşılaştırmam, fiyatları almam ve mevcut plana valid_untilve fiyatına göre yeni plan için kesintiyi hesaplamam gerekir . De ki: Bir yıllık A planına abone oldunuz, ancak 6 ay sonra B planına geçtiniz, bu nedenle 6 aylık A planı için ödenen fiyatın yarısının indirimini alıyorsunuz.

Ne merak ediyorum: Bir kullanıcı örneğin ücretsiz plana geçiş yaparsa, kullanıcı tekrar geçiş yapmak istiyorsa düşülebilir bir kredi var. Bu değeri ek bir alanda önbelleğe alır veya her zaman o kullanıcıyla ilgili tüm kayıtları hesaplar mısınız? Tablo düzeni hakkında bir şeyler ekler misiniz / değiştirir misiniz?

Kolay anlaşılabilirlik sorunu
Bir abonelik süresinin sonu geldiğinde, kullanıcı bilgilendirilir ve tekrar ödeme yaparak aboneliğini yenileme imkanına sahiptir. En kolay yol sadece güncelleme paid_atve valid_untilyeni abonelik seçenekleriyle olacaktır. Ancak, ödeme / abonelik geçmişi gibi birinin ihtiyaç duyabileceği her veriyi depolayıp saklamadığınızdan emin değilim.

Başka bir seçenek nerede, bunun için ek bir kayıt oluşturmak için olacağını from_planve to_planaynı tanımlayıcı (dolayısıyla "değişiklik yok" simgeleyen) yaşıyoruz. Ancak bu, hesap bakiyesinin bir şekilde hesaplanmasını engellemez mi?

Birisi beni bu tür abonelikleri işleyen mantıklarla ilgili olarak doğru yöne yönlendirebilirse, bunu çok takdir ediyorum.

GÜNCELLEME
Şimdiye kadar yardımlarınız için teşekkürler. Sorumun çok belirsiz olduğunu düşünüyorum, bu yüzden daha az soyutlama kullanarak daha kesin olmaya çalışacağım. Ne yazık ki, sorunumu henüz çözemedim.

Durum A
User seçebilir Subscription Plan A. Bu şu anda SubscriptionPlanChangetakip etmek için bir a depolar . Örneğin 5 ay Usersonra aboneliğini yükseltir Subscription Plan B. Böylece yeni aboneliğinin bedelini öder, kullanılmayan 7 ay için plan a'nın fiyatını düşürür.

Olgu B
3 ay sonra, Usergeri döner Subscription Plan A. Ödemesi gerekmiyor, ancak bunun için bir bakiye alıyor, böylece aboneliğin sonunda, yeni bakiyesi için bu bakiyeyi düşüyor.

Durum C
User bağımsız abonelik planları olan bir alt hizmet için bir abonelik planı seçebilir. Aynıdır Case Ave Case Bbu alt hizmet aboneliği için başvurabilir.

_Case D_ Kullanıcı aboneliklerinden birini iptal eder. Bu, dengesinin tamamlanmasıyla sonuçlanır.

Sorum (en azından şu anda) temel olarak bu verilerin nasıl düzgün bir şekilde saklanacağına bağlı olduğundan, iş analizi için abonelik geçmişini yeniden oluşturabilir ve bakiyeleri hesaplayabilir, aboneliklere dayalı ödenmemiş ödemeler vb. Alabilirim.

Ayrıca, dengenin örneğin kullanıcıların modelinde saklanıp saklanmayacağından veya saklanamadığından ancak saklanan verilere / geçmişe göre her zaman hesaplanabileceğinden emin değilim.

Dikkat edilmesi gereken bazı şeyler olsa da, sorunları ortaya çıkarmaları gerektiğini düşünmüyorum:

• Olması Usergerekmiyor, herhangi bir şey olabilir, bu yüzden Subscriberpolimorfik
• Plansille de planlar olmak zorunda değildir, ancak örneğin Magazinesbelirtildiği gibi olabilir . Vaka C ve Vaka D ile anlattığım şey bu .

Ne yazık ki, karmaşık bir sorunun cevabı genellikle karmaşıktır. Size tavsiyem sadece ilgili bilgileri kaydetmek ve daha büyük resmi oluşturmak için bir model kullanmak olacaktır.

Başka bir deyişle, SubscriptionPlanChanges tablonuzun anahtarı için aşağıdaki bilgilere sahip olacaktır:

• abone
• plan
• kadar geçerli

Bu şekilde, aynı abone için çakışabilecek birden fazla plana izin verirsiniz. Diğer alanlar:

• tarihine kadar geçerli
• kadar ödendi
• oranı (ücretsiz ise 0)

"Plan" dan veya "plan" a dikkat edin. Bunlara sahip olabilmenize rağmen, bilgiler gereksizdir ve kendi başınıza hesaplanabilir (bu tür bilgileri saklamak, tutarlı tutmak için ek göreviniz olduğu anlamına gelir). Yeni bir plan başladığında, mevcut planları değiştirmek yerine, onları bırakır ve yeni bir kayıt eklersiniz. Yeni plandan sonra başka bir çakışan plan varsa, silmek istediğinize karar verebilirsiniz (bu şekilde daha sezgisel). Bir aboneye bu planları yüklediğinizde, bunları "geçerli" tarihlerine göre sıralarsınız.

Bunu elde ettikten sonra, bir kullanıcının kredisini hesaplamak nispeten basittir. İki plan çakışamazsa, bir önceki planın "son tarihine kadar geçerli" ile bitiş tarihini belirlemek için geçerli planın "şu andan itibaren geçerli" tarihleri ​​arasındaki iki tarihten daha azını alırsınız. Başlangıç ​​tarihi, "geçerlilik tarihi" tarihi ile "ödenen bitiş tarihi" (tanımlanmışsa) arasındaki iki tarihten daha büyüktür. Ödeme (veya kredi) daha sonra bu planın yukarıda belirtilen başlangıç ​​ve bitiş tarihleri ​​arasındaki zaman aralığının çarpımı ile hesaplanabilir.

Bu şekilde, teoride bilmeniz gerekeni hesaplayabilirsiniz. Mevcut bir kayıt değiştirildiğinde, eklendiğinde veya silindiğinde değişeceği için hesaplanan değerleri kaydetmeye çalışmamayı öneririm.

Bu değerleri nasıl hesaplayacağınız varyasyonları, ek bir tür alanı eklenerek yönetilebilir. Kodunuzda, ana algoritmanızı karmaşık hesaplamalardan nispeten uzak tutmak için belirli planları hesaplama mantığını yönetmek için özel işleyiciler oluşturabilirsiniz. Herhangi bir tür belirtilmediğinde durum için bir işleyici oluşturmayı başarırsanız daha iyi olur, böylece yapmanız gereken tek şey, ihtiyacınız olan her türlü hesaplamayı yapmak için türüne göre uygun işleyiciyi çağırmaktır.

Umarım bu soruya cevap verir.

Yukarıdaki cevaba ek olarak, bir kredinin geçerli para birimine eşit olacağı kredili bir tablo oluşturacağım. Kullanıcı planı daha ucuz bir alternatifle değiştirdiğinde, kullanılmayan bakiye kredi olarak girer. Kullanıcının ödeyeceği bir şey olduğunda, önce kredileri kullanırsınız ve yalnızca kredilerin bitmesi veya mevcut olmaması durumunda ödeme istersiniz. Bu alternatif kullanılıyorsa, herhangi bir anlaşmazlık olursa kullanım senaryosunu yeniden oluşturabilmek için tabloyu işlem listesi olarak oluşturun. Misal:

Kimlik, UserId, TransactionDate, Credit (kullanıcı kredisi verdiğinizde pozitif ve kullanıcı krediyi kullandığında negatif)

Kullanıcının ona bakiyesini göstermesi için gereken kredileri toplamanız yeterlidir.

Umarım bu sizin için yararlıdır ...