Yükseltmeler ve eklentiler için planlar ve yetkilendirmeler veritabanı şeması

Neden planlar ve özellikler hızlıca karışır

Fiyat sayfasında planlar basit görünür: Basic, Pro, Enterprise. Gerçek karmaşa bu isimleri uygulamanızın içine gerçek erişim kurallarına dönüştürmeye çalıştığınız anda başlar.

Sabit kodlu özellik kontrolleri (örneğin if plan = Pro then allow X) ilk sürüm için işe yarar. Sonra fiyatlandırma değişir. Bir özellik Pro'dan Basic'e geçer, yeni bir eklenti ortaya çıkar ya da bir satış anlaşması özel bir paket içerir. Bir anda aynı kuralı API'lerde, UI'da, mobil uygulamalarda ve arka plan işleri içinde kopyaladığınızı görürsünüz. Bir yeri değiştirir, diğerini unutursunuz. Kullanıcılar fark eder.

İkinci bir sorun zaman boyutudur. Abonelikler statik bir etiket değildir; dönem içinde değişir. Birisi bugün yükseltir, gelecek ay düşürür, duraklatır ya da kalan ücretli süre varken iptal eder. Veritabanınız sadece “mevcut plan”ı saklıyorsa zaman çizelgesini kaybedersiniz ve daha sonra temel sorulara cevap veremezsiniz: Geçen Salı neye erişimleri vardı? Destek neden geri ödemeyi onayladı?

Eklentiler işi daha da karmaşıklaştırır çünkü planların üzerinden geçerler. Bir eklenti fazla koltuk açabilir, bir limiti kaldırabilir veya belirli bir özelliği etkinleştirebilir. İnsanlar bunu herhangi bir planda satın alabilir, sonra kaldırabilir veya düşürmeden sonra saklayabilir. Kural koda gömülü ise büyüyen özel durumlar yığınınız olur.

Genellikle basit tasarımları bozan durumlar şunlardır:

• Dönem ortasında yükseltme: erişim hemen değişmeli, faturalandırma proratasyonu farklı kurallara tabi olabilir.
• Planlı düşürme: erişim ücretli dönem bitene kadar "daha yüksek" kalabilir.
• Grandfathering (eski müşterilere ayrı haklar): eski müşteriler yeni müşterilerin alamadığı bir özelliği korur.
• Özel anlaşmalar: aynı plan adına sahip hesaplardan biri Özellik A'yı alır ama Özellik B'yi almaz.
• Denetim ihtiyaçları: destek, finans veya uyumluluk "tam olarak ne etkinleştirildi ve ne zaman?" diye sorar.

Hedef basit: fiyatlandırma değiştikçe iş mantığını her seferinde yeniden yazmadan değişen esnek bir erişim kontrol modeli. Soruyu tek bir yerde sormak istersiniz: "bunu yapabilirler mi?" ve veritabanında bu cevabı açıklayan bir geçmiş olsun.

Bu makalenin sonunda kopyalayabileceğiniz bir şema deseni olacak: planlar ve eklentiler girdi olur, yetkilendirmeler ise özellik erişimi için tek gerçek kaynak haline gelir. Aynı yaklaşım AppMaster gibi no-code yapılar için de uygundur; çünkü kuralları veride tutar ve backend, web uygulaması ve mobil uygulamalardan tutarlı şekilde sorgulayabilirsiniz.

Ana terimler: plan, eklenti, yetki ve erişim

Birçok abonelik sorunu aslında bir kelime sorunu olarak başlar. Herkes aynı kelimeyi farklı şeyler için kullanırsa şemanız özel durumlara dönüşür.

Planlar ve yetkilendirmeler veritabanı şemasında ayrı tutmanız gereken terimler:

• Plan: Birinin abone olduğunda aldığı varsayılan paket (örneğin Basic veya Pro). Plan genellikle temel limitleri ve dahil özellikleri belirler.
• Eklenti (Add-on): Temeli değiştiren isteğe bağlı satın alma (örneğin "ek koltuklar" veya "gelişmiş raporlama"). Eklentiler plan değişmeden eklenip kaldırılabilmeli.
• Yetkilendirme (Entitlement): Plan + eklentiler + geçersiz kılmalar birleştirildikten sonra ortaya çıkan "şu an neye sahipler"in hesaplanmış sonucu. Uygulamanızın sorgulayacağı şey budur.
• İzin (Permission veya capability): Bir kişinin yapabileceği spesifik bir eylem (örneğin "veri dışa aktar" veya "faturalamayı yönet"). İzinler genellikle rol ile yetkilendirmelerin birleşimine bağlıdır.
• Erişim (Access): Uygulamanın kuralları uyguladığında ortaya çıkan gerçek dünya sonucu (ekran bir özelliği gösterir/gizler, bir API çağrısına izin verilir/engellenir, bir limit uygulanır).

Özellik bayrakları (feature flags) ilgili ama farklıdır. Bir özellik bayrağı genellikle ürünün bir anahtarıdır (kademeli açılışlar, deneyler, bir olay sırasında özelliği kapatmak). Bir yetki ise müşteriye özel, ödediği veya verdiğiniz erişime dayanan bir şeydir. Bayrakları, faturalandırmaya dokunmadan davranışı gruplar için değiştirmek istediğinizde kullanın. Yetkilendirmeleri ise erişimin bir abonelik, fatura veya sözleşmeye uyması gerektiğinde kullanın.

Kapsam (scope) başka bir kafa karıştırıcı kaynaktır. Bunları net tutun:

• Kullanıcı: Tek bir kişi. Roller için (admin vs üye) ve kişisel limitler için uygundur.
• Hesap (Account/customer): Ödeyen varlık. Faturalama bilgileri ve abonelik sahipliği için uygundur.
• Çalışma alanı (Workspace/project/team): İşin yapıldığı yer. Birçok ürün yetkilendirmeleri burada uygular (koltuklar, depolama, etkin modüller).

Zaman önemlidir çünkü erişim değişir. Bunu doğrudan modelleyin:

• Başlangıç ve bitiş: Bir yetki yalnızca belirli bir pencerede etkin olabilir (deneme, promosyon, yıllık sözleşme).
• Planlı değişiklik: Yükseltmeler hemen başlayabilir; düşürmeler genellikle yenileme zamanında başlar.
• Grace ve iptal: Ödeme başarısız olduğunda sınırlı erişime izin verebilirsiniz, ancak belirli bir bitiş tarihine kadar.

Örnek: Bir şirket Pro üzerindeyken ortada "Advanced Reporting" eklentisi ekliyor ve sonra bir sonraki döngüde Basic'e düşürme planlıyor. Plan daha sonra değişir, eklenti hemen başlar ve yetki katmanı tek yer olarak kalır: "Bu çalışma alanı bugün gelişmiş raporları kullanabilir mi?"

Planlar ve özellikler için basit bir çekirdek şema

İyi bir planlar ve yetkilendirmeler veritabanı şeması küçük başlar: sattığınız şeyi (planlar ve eklentiler) insanlara ne yaptırdığıyla (özellikler) ayırın. Bu iki fikri temiz tutarsanız, yükseltmeler ve yeni eklentiler veri değişiklikleri olur, kod yeniden yazmaları olmaz.

Çoğu abonelik ürünü için işe yarayan pratik bir temel tablo seti:

• products: satılan şey (Temel plan, Takım planı, Ek koltuk eklentisi, Öncelikli destek eklentisi).
• plans: isteğe bağlı; planların plan-özel alanları varsa (faturalama aralığı, genel gösterim sırası) ayrı tutabilirsiniz. Birçok ekip planları products içinde product_type sütunu ile saklar.
• features: yetenek kataloğu (API erişimi, maksimum proje sayısı, dışa aktarım, SSO, SMS kredileri).
• product_features (veya plan_features): hangi ürünün hangi özellikleri sağladığını söyleyen bağlantı tablosu; genellikle bir değer içerir.

Bu bağlantı tablosu gücün çoğunu barındırır. Özellikler nadiren yalnızca açık/kapalı olur. Bir plan max_projects = 10 içerebilirken bir eklenti +5 ekleyebilir. Bu yüzden product_features en azından şunları desteklemeli:

• feature_value (sayı, metin, JSON veya ayrı sütunlar)
• value_type (boolean, integer, enum, json)
• grant_mode (yerine yazma vs ekleme), böylece bir eklenti temel limiti üzerine "+5 koltuk" ekleyebilir

Eklentileri de ürün olarak modelleyin. Tek fark satın alma şekilleridir. Bir temel plan ürünü "bir tane" iken, bir eklenti çoklu miktara izin verebilir. Ancak her ikisi de özelliklere aynı şekilde eşlenir. Bu, kodda "eğer eklenti X ise özellik Y'i etkinleştir" gibi özel durumları önler.

Özellikler veride olmalı, kod sabiti olarak değil. Özellik kontrollerini birden fazla serviste kodlarsanız sonunda tutarsızlıklar çıkar (web evet der, mobil hayır der, backend farklı). Özellikler veritabanında olunca uygulama tek bir tutarlı soruyu sorar ve satırları düzenleyerek değişiklikleri dağıtabilirsiniz.

İsimlendirme beklenenden daha önemlidir. Pazarlama adı değişse bile asla değişmeyecek kararlı tanımlayıcılar kullanın:

• feature_key örneğin max_projects, sso, priority_support
• product_code örneğin plan_starter_monthly, addon_extra_seats

Görünen etiketleri ayrı tutun (feature_name, product_name). AppMaster’ın Data Designer ile PostgreSQL kullanıyorsanız bu anahtarları benzersiz alanlar olarak tutmak hemen fayda sağlar: yeniden üretirken entegrasyonlar ve raporlama sabit kalır.

Yetkilendirme katmanı: "yapabilirler mi?" sorusunun tek adresi

Çoğu abonelik sistemi, "ne aldıkları" bir yerde saklanırken "ne yapabildikleri" beş farklı kod yolunda hesaplandığında yan yoldan çıkar. Çözüm bir yetkilendirme katmanıdır: bir konu için belirli bir zamanda etkin erişimi temsil eden tek bir tablo (veya görünüm).

Yükseltmeleri, düşürmeleri, denemeleri ve tek seferlik hakları yönetebilen bir şema hedefliyorsanız bu katman her şeyi öngörülebilir kılan kısımdır.

Pratik bir entitlements (yetkiler) tablosu

Her satırı şu iddia olarak düşünün: "bu konu bu özelliğe bu değerle bu zamandan bu zamana kadar bu kaynak nedeniyle sahip." Yaygın bir şekil şöyle görünür:

• subject_type (ör. "account", "user", "org") ve subject_id
• feature_id
• value (o özellik için etkin değer)
• source (hangi kaynaktan geldi: "direct", "plan", "addon", "default")
• starts_at ve ends_at (süresiz erişim için nullable ends_at)

Değeri birkaç yolla uygulayabilirsiniz: tek bir text/JSON sütunu artı value_type, ya da value_bool, value_int, value_text gibi ayrı sütunlar. Sıkıcı ama sorgulanabilir tutun.

Çoğu ürün için yeterli değer tipleri

Özellikler her zaman açık/kapalı değildir. Bu değer tipleri gerçek faturalama ve erişim ihtiyaçlarını karşılar:

• Boolean: etkin/pasif ("can_export" = true)
• Kota sayısı: limit ("seats" = 10, "api_calls" = 100000)
• Tier seviyesi: bir rütbe ("support_tier" = 2)
• String: bir mod veya varyant ("data_retention" = "90_days")

Öncelik: çakışmalar nasıl çözülür

Çakışmalar normaldir. Bir kullanıcı 5 koltuk veren planda olabilir, 10 ek koltuk için eklenti satın alabilir ve ayrıca destekten manuel bir yetki alabilir.

Açık bir kural belirleyin ve her yerde ona bağlı kalın:

1. Doğrudan verilen yetkiler planın üstüne yazar
2. Sonra eklentiler gelir
3. En sonda varsayılanlar

Basit bir yaklaşım, tüm aday satırları (plan kaynaklı, eklenti kaynaklı, doğrudan) saklamak ve subject_id + feature_id başına bir "kazanan" hesaplamak için kaynak önceliğine ve sonra en yeni starts_at sırasına göre sıralamaktır.

Somut bir senaryo: bir müşteri bugün planını düşürüyor ama ay sonunda bitecek bir eklenti için zaten ödeme yapmış. Entitlements üzerindeki starts_at/ends_at ile, plan tabanlı özelliklerde düşürme hemen etkili olurken eklenti yetkisi ends_at'a kadar aktif kalır. Uygulamanız "yapabilirler mi?" sorusuna özel durum mantığı yerine tek bir sorguyla cevap verebilir.

Abonelikler, öğeler ve zamanla sınırlı erişim

Plan kataloğunuz (planlar, eklentiler, özellikler) "ne"dir. Abonelikler ise "kimde ne var ve ne zaman"dır. Bunları ayrı tuttuğunuzda yükseltmeler ve iptaller korkutucu olmaktan çıkar.

Pratik bir desen: bir hesap için bir abonelik ve altında birçok abonelik öğesi (temel plan için bir, artı sıfır veya daha fazla eklenti). Bu, erişim kurallarını yeniden yazmadan zaman içinde değişiklikleri kaydetmek için temiz bir alan sağlar.

Satın alma zaman çizelgesini modellemek için temel tablolar

Basit ve sorgulanması kolay iki tabloyla tutabilirsiniz:

• subscriptions: id, account_id, status (active, trialing, canceled, past_due), started_at, current_period_start, current_period_end, canceled_at (nullable)
• subscription_items: id, subscription_id, item_type (plan, addon), plan_id/addon_id, quantity, started_at, ends_at (nullable), source (stripe, manual, promo)

Ortak bir detay: her öğeyi kendi tarihleriyle saklayın. Böylece bir eklentiyi sadece 30 günlüğüne verebilir veya müşteri yenilemeyi iptal ettiğinde planın ücretli dönemi bitene kadar devam etmesine izin verebilirsiniz.

Proratasyon ve faturalamayı erişim mantığından uzak tutun

Proratasyon, faturalar ve ödeme denemeleri faturalama problemleridir. Özellik erişimi ise yetkilendirme problemidir. Erişimi fatura satırlarından hesaplamaya çalışmayın.

Bunun yerine, faturalama olaylarının abonelik kayıtlarını güncellemesine izin verin (örneğin, current_period_end'i uzat, yeni bir subscription_item oluştur veya ends_at ayarla). Uygulamanız erişim sorularına faturalama hesaplamaları yerine abonelik zaman çizelgesinden (ve daha sonra yetkilendirme katmanından) cevap versin.

Sürpriz olmadan planlı değişiklikler

Yükseltmeler ve düşürmeler genellikle belirli bir anda yürürlüğe girer:

• Aboneliklerde tek bir plan değişikliği için pending_plan_id ve change_at ekleyin.
• Ya da birden fazla gelecekteki değişiklik gerekiyorsa subscription_changes tablosu (subscription_id, effective_at, from_plan_id, to_plan_id, reason) kullanın.

Bu, "düşürmeler dönem sonunda olur" gibi kuralları kodun rastgele yerlerine sabitlemeyi önler. Zamanlama veridir.

Denemelerin (trials) yeri

Denemeler yalnızca farklı bir kaynaktan zamanla sınırlı erişimdir. İki temiz seçenek:

• Denemeyi abonelik durumu olarak ele alın (trialing) ve trial_start/trial_end tarihleri tutun.
• Ya da trial için başlatma/bitiş tarihli öğe/yetki verin ve source = trial olarak kaydedin.

AppMaster içinde inşa ediyorsanız bu tablolar Data Designer ile güzel eşleşir ve tarihler "şu anda ne aktif"i özel durum olmadan sorgulamayı basitleştirir.

Adım adım: deseni uygulamak

İyi bir planlar ve yetkilendirmeler veritabanı şeması tek bir vaatte başlar: özellik mantığı veride yaşar, kod yollarına dağılmaz. Uygulamanız tek bir soru sormalı - "şu anda etkin yetkilendirmeler nelerdir?" - ve net bir cevap almalı.

1) Özellikleri kararlı anahtarlarla tanımlayın

feature tablosu oluşturun; UI etiketi değişse bile asla yeniden adlandırmayacağınız kararlı, okunabilir bir anahtar kullanın. İyi anahtarlar export_csv, api_calls_per_month, seats gibidir.

Sistemin değeri nasıl değerlendireceğini bilmesi için bir tip ekleyin: boolean (açık/kapalı) veya numeric (limitler/kotalar). Sıkıcı ama tutarlı tutun.

2) Planları ve eklentileri yetkilendirmelere eşleyin

Şimdi iki gerçek kaynağa ihtiyacınız var: bir plan neler içerir ve her eklenti ne verir.

Basit pratik sıra şöyle olabilir:

• Tüm özellikleri kararlı anahtarlar ve bir değer tipi ile tek bir feature tablosuna koyun.
• Her özelliğe bir değer veren plan ve plan_entitlement oluşturun (örneğin seats = 5, export_csv = true).
• Ek değer veren addon ve addon_entitlement oluşturun (örneğin seats + 10, api_calls_per_month + 50000, veya priority_support = true).
• Değerleri nasıl birleştireceğinize karar verin: booleanlar genelde OR ile, sayısal limitler genelde MAX ile (yüksek olan kazanır), koltuk benzeri miktarlar ise SUM ile toplanır.
• Yetkilendirmelerin başladığı ve bittiği zamanı kaydedin ki yükseltmeler, iptaller ve proratasyon erişim kontrollerini bozmasın.

AppMaster’da inşa ediyorsanız bu tabloları Data Designer’da modelleyebilir ve birleştirme kurallarını küçük bir "policy" tablosu veya enum olarak Business Process mantığınızda tutabilirsiniz.

3) "Etkili yetkilendirmeler" üretin

İki seçeneğiniz var: okuma sırasında hesapla (her seferinde sorgula ve birleştir) ya da bir şey değiştiğinde önbelleğe alınmış bir anlık görüntü üretin. Çoğu uygulama için anlık görüntüler (snapshot) yük altında daha basit ve hızlıdır.

Yaygın yaklaşım, hesap başına her özellik için sonucun saklandığı account_entitlement tablosu ve valid_from ile valid_to tutmaktır.

4) Erişimi tek bir kontrol ile zorunlu kılın

Kuralları ekranlara, uç noktalara ve arka plan işlerine yaymayın. Etkili yetkilendirmeleri okuyan ve karar veren tek bir fonksiyon koyun.

can(account_id, feature_key, needed_value=1):
  ent = get_effective_entitlement(account_id, feature_key, now)
  if ent.type == "bool": return ent.value == true
  if ent.type == "number": return ent.value >= needed_value

Her şey can(...) fonksiyonunu çağırdığında, yükseltmeler ve eklentiler veri güncellemeleri olur, kod yeniden yazmaları değil.

Örnek senaryo: sürpriz olmadan yükseltme ve eklenti

6 kişilik bir destek ekibi Starter planında. Starter planı 3 agent koltuğu ve ayda 1000 SMS içeriyor. Ay ortasında 6 personele çıkıyorlar ve ekstra 5000 SMS paketi istiyorlar. Bunu özel durum kodu olmadan çalışır hale getirmek istersiniz.

Gün 1: Starter ile başlarlar

Hesap için bir subscription oluşturursunuz (örneğin 1 Ocak - 31 Ocak dönem). Ardından plana ait bir subscription_item eklersiniz.

Checkout sırasında (veya gece işiyle) o dönem için yetki kayıtları yazarsınız:

• entitlement_grant: agent_seats, değer 3, başlangıç 1 Ocak, bitiş 31 Ocak
• entitlement_grant: sms_messages, değer 1000, başlangıç 1 Ocak, bitiş 31 Ocak

Uygulamanız asla "hangi plandalar?" diye sormaz. "Şu anki etkili yetki nedir?" diye sorar ve koltuk = 3, SMS = 1000 cevabını alır.

Gün 15: Pro'ya yükseltme ve aynı gün SMS paketi ekleme

15 Ocak'ta Pro'ya yükselirler (Pro 10 agent koltuğu ve 2000 SMS içerir). Eski yetkileri düzenlemezsiniz. Yeni kayıtlar eklersiniz:

• Eski plan öğesini kapatın: subscription_item (Starter) end = 15 Ocak
• Yeni plan öğesi oluşturun: subscription_item (Pro) start = 15 Ocak, end = 31 Ocak
• Yeni eklenti öğesi ekleyin: subscription_item (SMS Pack 5000) start = 15 Ocak, end = 31 Ocak

Aynı dönem için yetki kayıtları eklenir:

• entitlement_grant: agent_seats, değer 10, başlangıç 15 Ocak, bitiş 31 Ocak
• entitlement_grant: sms_messages, değer 2000, başlangıç 15 Ocak, bitiş 31 Ocak
• entitlement_grant: sms_messages, değer 5000, başlangıç 15 Ocak, bitiş 31 Ocak

15 Ocak'ta ne olur?

• Koltuklar: etkili koltuk sayısı 10 olur (koltuklar için "yüksek olan kazanır" kuralı seçilmişse). O gün 3 kişiyi daha ekleyebilirler.
• SMS: kalan dönem için etkili SMS 7000 olur (mesaj paketleri için "toplam ekle" kuralı seçilmişse).

Mevcut kullanım taşınmak zorunda değildir. Kullanım tablonuz mesaj sayımına devam eder; yetki kontrolü sadece bu dönemdeki etkin limitle karşılaştırır.

Gün 25: Dönem sonuna kadar erişimi koruyarak düşürme planlama

25 Ocak'ta Şubat başı için Starter'a düşürme planlarlar. Ocak yetkilerini değiştirmezsiniz. Gelecek dönem için öğeler (veya gelecekteki yetkiler) oluşturursunuz:

• subscription_item (Starter) start 1 Şubat, end 28 Şubat
• 1 Şubat'ta başlayacak SMS paketi yok

Sonuç: Ocak boyunca Pro koltukları ve SMS paketi devam eder. 1 Şubat'ta etkili koltuk 3'e düşer ve yeni dönemde SMS Starter limitlerine sıfırlanır. Bu açıkça anlaşılır ve AppMaster gibi no-code iş akışlarına doğrudan uyar: tarihler yeni satırlar oluşturur ve yetki sorgusu değişmez.

Yaygın hatalar ve tuzaklar

Çoğu abonelik hatası fatura hatası değil, üründe mantığın dağılması sonucu oluşan erişim hatasıdır. Planlar ve yetkilendirmeler şemasını kırmanın en hızlı yolu "yapabilirler mi?" sorusuna beş farklı yerde cevap vermektir.

Klasik bir başarısızlık, kuralları UI'da, API'de ve arka plan işlerinde ayrı ayrı sert kodlamaktır. UI bir düğmeyi gizler, API uç noktası engellemeyi unutur ve gece işi hala çalışmaya devam eder çünkü başka bir şeyi kontrol eder. Sonuçta "bazen çalışıyor" raporları ortaya çıkar ve yeniden üretmesi zordur.

Bir diğer tuzak, plan_id kontrolleri kullanmaktır. İlk başta basit gelir (Plan A dışa aktarabilir, Plan B yapamaz), ama eklenti, grandfathering, ücretsiz deneme veya kurumsal istisna eklediğiniz anda çöker. "if plan is Pro then allow..." derseniz uzun süre yönetmeniz gereken bir labirent inşa ediyorsunuz.

Zaman ve iptal kenar durumları

Erişim ayrıca yalnızca has_export = true gibi boolean saklayıp tarihler eklemediğinizde "takılı kalır". İptaller, iade talepleri, chargeback ve dönem ortası düşürmeler tümü zaman sınırlarını gerektirir. starts_at ve ends_at yoksa yanlışlıkla kalıcı erişim verebilir veya erişimi çok erken alabilirsiniz.

Basit bir kontrol:

• Her yetki kaydının bir kaynağı (plan, eklenti, manuel geçersiz kılma) ve bir zaman aralığı olmalı.
• Her erişim kararı "şu an start ile end arasında mı" kullanmalı (null end için net kurallarla).
• Arka plan işleri çalışırken dünün durumunu varsaymamalı, yetkileri çalışma zamanında tekrar kontrol etmeli.

Faturalama ve erişimi karıştırmayın

Ekipler ayrıca fatura kayıtları ile erişim kurallarını aynı tabloda karıştırarak sorun yaşar. Faturalama faturalar, vergiler, proratasyon, sağlayıcı kimlikleri ve yeniden deneme durumlarını gerektirir. Erişimse açık özellik anahtarları ve zaman pencerelerini. İkisi karışırsa bir fatura geçişi ürün kesintesine yol açabilir.

Son olarak, birçok sistem bir denetim izi atlar. Bir kullanıcı "neden dışa aktarabiliyorum?" diye sorduğunda şu gibi bir cevap vermeniz gerekir: "Add-on X tarafından 2026-01-01 ile 2026-02-01 arasında etkinleştirildi" veya "Destek tarafından manuel verildi, ticket 1842." Yoksa destek ve mühendislik tahmin eder.

AppMaster ile inşa ediyorsanız Data Designer modelinizde denetim alanlarını tutun ve "yapabilirler mi?" kontrolünü web, mobil ve zamanlı akışlar tarafından kullanılan tek bir Business Process yapın.

Yayına almadan önce hızlı kontrol listesi

Planlar ve yetkilendirmeler veritabanı şemanızı yayına almadan önce gerçek sorularla bir tur daha geçin. Hedef, erişimin açıklanabilir, test edilebilir ve değişime uygun olmasıdır.

Gerçeklik kontrolü soruları

Bir kullanıcı ve bir özellik seçin, sonra sonucu destek veya finansmana açıklayacağınız şekilde anlatın. Sadece "Pro'dalar" diyebiliyorsanız (ya da daha kötüsü "kod öyle diyor"), biri dönem ortasında yükseltme yaptığında veya tek seferlik anlaşma çıktığında acı çekersiniz.

Kısa kontrol listesi:

• Kullanıcıya neden erişim verildiğini yalnızca verilerle (abonelik öğeleri, eklentiler, geçersiz kılmalar ve zaman pencereleri) açıklayabiliyor musunuz, uygulama kodunu okumadan?
• Tüm erişim kontrolleri sabit feature anahtarlarına (feature.export_csv gibi) mı dayanıyor, yoksa plan isimlerine mi? Plan isimleri değişir; özellik anahtarları değişmemeli.
• Yetkilendirmelerin deneme, grace period ve planlı iptaller dahil açık başlangıç ve bitiş zamanları var mı? Zaman eksikse düşürmeler tartışma konusu olur.
• Bir müşteriye erişimi bir geçersiz kılma kaydı ile verebilir veya kaldırabilir misiniz, mantığı dallandırmadan? Bu, "bu ay onlara 10 ek koltuk ver" gibi istekleri özel kod olmadan yönetmeyi sağlar.
• Bir yükseltme ve düşürmeyi birkaç örnek satırla test edebiliyor ve öngörülebilir sonuç alabiliyor musunuz? Eğer simüle etmek için karmaşık bir script gerekiyorsa modeliniz çok örtük demektir.

Pratik bir test: üç kullanıcı oluşturun (yeni, dönem ortasında yükselten, iptal eden) ve bir eklenti ("ek koltuk" veya "gelişmiş raporlar"). Ardından her biri için erişim sorgusunu çalıştırın. Sonuçlar açık ve açıklanabilir ise hazırsınız demektir.

AppMaster gibi bir araç kullanıyorsanız aynı kuralı koruyun: her web ve mobil ekran aynı cevabı alacak şekilde "yapabilirler mi?" sorusunu tek bir sorgu veya Business Process cevaplasın.

Sonraki adımlar: yükseltmeleri bakımı kolay hale getirin

Yükseltmeleri mantıklı tutmanın en iyi yolu düşündüğünüzden daha küçük başlamaktır. Gerçek değeri sunan bir avuç özellik seçin (5-10 yeterlidir) ve "Bu hesap şu an X yapabilir mi?" sorusunu cevaplayan tek bir yetki sorgusu veya fonksiyonu inşa edin. Bunu tek bir yerde cevaplayamıyorsanız yükseltmeler hep riskli görünecektir.

O bir kontrol çalıştığında, yükseltme yollarını ürün davranışı olarak değerlendirin, sadece faturalama davranışı değil. Garip kenar durumlarını yakalamanın en hızlı yolu gerçek müşteri hareketlerine dayalı küçük erişim testleri yazmaktır.

Hemen fayda sağlayacak pratik adımlar:

• Minimal bir özellik kataloğu tanımlayın ve her planı net yetkilendirme setlerine eşleyin.
• Eklentileri plan kurallarına gömmek yerine ayrı "öğe" olarak ekleyin; bu, eklentilerle veya kaldırmalarla yetkilendirmeleri genişletmeyi kolaylaştırır.
• Ortak yollar için 5-10 erişim testi yazın (dönem ortası yükseltme, yenilemede düşürme, eklenti ekleme ve kaldırma, denemeden ödemeye geçiş, grace period).
• Fiyat değişikliklerini veri odaklı yapın: plan satırlarını, özellik eşlemelerini ve yetki kayıtlarını güncelleyin; uygulama koduna dokunmayın.
• Her yeni plan veya eklenti en az bir testle gelsin; böylece yeni davranışların beklendiği şekilde çalıştığından emin olun.

No-code backend kullansanız bile bu deseni temizce modelleyebilirsiniz. AppMaster'da Data Designer çekirdek tabloları (planlar, özellikler, abonelikler, abonelik öğeleri, yetkilendirmeler) için uygundur. Business Process Editor ise aktif yetkilendirmeleri yükleme, zaman pencerelerini uygulama ve izin/verme kararını döndürme akışını barındırabilir; böylece uç noktalarda dağınık kontroller yerine tek bir mantık kullanırsınız.

Kazanç, fiyat değiştiğinde gösterir: kuralları yeniden yazmak yerine veriyi düzenlersiniz: bir özellik Pro'dan eklentiye taşınır, bir yetki süresi değişir veya eski bir plan eski haklarını korur. Erişim mantığınız sabit kalır ve yükseltmeler kontrollü veri güncellemeleri olur, kod sprintleri değil.

Hızlı doğrulama yapmak isterseniz, bir yükseltme ve bir eklentiyi uçtan uca modelleyip bu erişim testlerini çalıştırarak başlayın.