Gdy logika SaaS zaczyna się od warunków takich jak if ($tenant->plan === 'pro'), wydaje się to prostym rozwiązaniem. Problem pojawia się przy drugiej zmianie katalogu: plan zostaje przemianowany, funkcjonalność jest sprzedawana osobno, klient zachowuje wcześniejsze warunki lub wsparcie techniczne musi tymczasowo coś włączyć. Wtedy nazwa handlowa przestaje opisywać stabilną regułę i zostaje rozproszona między kontrolerami, zadaniami harmonogramu, zapytaniami, API i interfejsem.
Zarządzanie funkcjonalnościami w SaaS PHP musi przekładać ofertę handlową na weryfikowalne decyzje domenowe. Kod nie powinien pytać, czy firma jest „Pro”, lecz czy może wykonać konkretne działanie, z jakim limitem, na jakich warunkach i do kiedy. To rozdzielenie pozwala zmieniać ceny lub pakiety bez przepisywania reguł operacyjnych.
Rozdzielenie planu, funkcjonalności, limitu, uprawnienia i konfiguracji
Te pojęcia są powiązane, lecz nie są zamienne. Plan jest pakietem handlowym. Funkcjonalność udostępnia funkcję produktu, taką jak eksport danych, tworzenie automatyzacji lub korzystanie z integracji. Limit określa dozwoloną liczbę lub tempo, na przykład aktywne projekty, rozliczanych użytkowników albo żądania API na okres.
Uprawnienie odpowiada na inne pytanie: która tożsamość może wykonać działanie w ramach firmy. To, że organizacja ma funkcjonalność eksportowania danych, nie oznacza, że każdy użytkownik może je eksportować. Wreszcie konfiguracja klienta to opcje dostępne dla konkretnej firmy, takie jak wybrany dostawca tożsamości, polityka retencji lub szablon powiadomień. Nie należy używać swobodnej konfiguracji do ukrywania decyzji handlowych lub dotyczących autoryzacji.
- Plan: handlowa kompozycja uprawnień i limitów.
- Funkcjonalność: reguła funkcjonalna wyrażona w kategoriach produktu.
- Limit: mierzalny próg powiązany z funkcjonalnością lub zasobem.
- Uprawnienie: autoryzacja aktora do wykonania działania.
- Konfiguracja: parametr zachowania dostępny w ramach już przyznanych reguł.
Decyzja może wymagać wszystkich warstw. Aby utworzyć automatyzację, firma potrzebuje odpowiedniej funkcjonalności, liczba aktywnych automatyzacji musi pozostawać poniżej limitu, a użytkownik musi mieć uprawnienie administracyjne. Następnie przepływ może zweryfikować konfigurację miejsca docelowego.
Modelowanie reguł domenowych, a nie nazw planów
Utrzymuj stabilny katalog funkcjonalności z identyfikatorami technicznymi niezależnymi od marketingu: automation.create, data.export lub api.webhooks. Katalog może zawierać typ oczekiwanej wartości: wartość logiczną, liczbę całkowitą, zbiór opcji lub ustrukturyzowaną politykę. Identyfikator wyraża potrzebę produktu; nie powinien zawierać nazwy planu ani kampanii.
Przypisanie handlowe można rozstrzygać w osobnej warstwie. Obowiązujący plan zapewnia zestaw przyznań, ale mogą również istnieć dodatki, migracje starszych klientów i jawne wyjątki. Wynikiem dla każdej firmy jest ustalenie obowiązujących uprawnień wraz z informacją o ich pochodzeniu.
funkcjonalność: automation.create
wartość efektywna: true
pochodzenie: dodatek do automatyzacji
ważność: pozostaje w mocy do czasu anulowania
To pochodzenie jest niezbędne. Jeśli funkcjonalność jest aktywna, produkt, wsparcie techniczne i rozliczenia muszą wiedzieć, czy wynika ona z obecnego planu, z wcześniejszego zapisu czy z wyjątku z datą wygaśnięcia. Unikaj przechowywania w firmie wyłącznie pola plan i wyprowadzania całej reszty w każdym miejscu użycia.
Jedna usługa decyzyjna
W PHP udostępnij usługę domenową, na przykład EntitlementResolver lub CapabilityGate, która otrzymuje firmę, funkcjonalność i niezbędny kontekst. Powinna zwracać możliwą do wyjaśnienia decyzję, a nie tylko wartość logiczną: dozwolone lub odrzucone, ustaloną wartość, powód, regułę źródłową i datę oceny. Ta data oznacza moment, w którym resolver ustalił decyzję, i pozwala poprawnie interpretować okresy ważności, wygaśnięcia oraz późniejsze zmiany planu. Kontrolery, komendy, listenery i asynchroniczne workery odwołują się do tej usługi; nie odtwarzają własnych zapytań dotyczących subskrypcji.
Definiowanie mierzalnych limitów przed ich implementacją
Niejednoznaczny limit rodzi konflikty i błędy implementacyjne. „Do 100 użytkowników” wymaga odpowiedzi, kto liczy się jako użytkownik: oczekujący zaproszony, zawieszony, członek usunięty w trakcie cyklu, konto usługi? „Tysiąc eksportów” wymaga zdefiniowania okresu, strefy czasowej, ponownych prób i tego, czy nieudany eksport zużywa limit.
Dla każdego limitu udokumentuj co najmniej:
- Zasób, zdarzenie lub zużycie, które jest zliczane.
- Zakres: firma, projekt, użytkownik lub integracja.
- Okno: całkowity czas obowiązywania, dzień kalendarzowy, miesiąc rozliczeniowy lub okno kroczące.
- Moment kontroli: przed utworzeniem, przy aktywacji, przy wysłaniu lub po konsolidacji.
- Reakcję: blokowanie, zezwolenie z ostrzeżeniem, kolejkowanie, degradację lub wymaganie zatwierdzenia.
- Obsługę współbieżności, ponownych prób, anulowań i wycofania.
Limity aktywnych obiektów zwykle waliduje się operacją transakcyjną lub rezerwacją, która zapobiega przekroczeniu progu przy współbieżności. Limity zużycia wymagają licznika o jasnej semantyce oraz idempotencji za pomocą klucza zdarzenia. Nie polegaj wyłącznie na liczniku wyświetlanym w interfejsie: dwa jednoczesne żądania mogą przejść wstępną kontrolę i przekroczyć maksimum.
Rozróżniaj również ostrzeżenie i blokadę. Alert przy 80% poprawia przewidywalność, ale nie zastępuje rzeczywistej ochrony w punkcie, w którym zasób jest tworzony lub wykonywany.
Stosowanie reguł we wszystkich ścieżkach wykonania
Ukrycie przycisku jest poprawą doświadczenia użytkownika, a nie kontrolą dostępu. Walidacja musi istnieć w przypadku użycia po stronie serwera, który wykonuje działanie. Dzięki temu obejmuje interfejs webowy, publiczne API, integracje i wywołania wewnętrzne.
Procesy asynchroniczne wymagają dodatkowej decyzji: sprawdzenia przy kolejkowaniu i ponownego sprawdzenia przy wykonaniu, gdy zadanie może zostać opóźnione. Jeśli firma utraci funkcjonalność między tymi momentami, polityka musi określać, czy zadanie zostaje anulowane, kończy się, ponieważ zostało wcześniej zaakceptowane, czy wymaga weryfikacji. Wybór zależy od typu operacji, ale powinien być spójny i rejestrowany.
Narzędzia wsparcia technicznego i administracji nie powinny po cichu omijać reguł. Mogą działać z inną autoryzacją administracyjną, ale muszą pozostawiać ślad audytowy i wskazywać, czy tworzą formalne przyznanie, korektę danych czy działanie wyjątkowe.
Zarządzanie zmianami, uprawnieniami starszych klientów i wyjątkami bez rozgałęziania produktu
Zmiana planu to nie tylko aktualizacja etykiety. Może obniżyć limit poniżej bieżącego użycia lub wycofać funkcjonalność, która podtrzymuje aktywne procesy. Zdefiniuj polityki według typu zasobu: uniemożliwienie nowych utworzeń i zachowanie istniejących, jawne dezaktywowanie nadmiarowych elementów, przyznanie okresu przejściowego lub zażądanie wyboru od administratora firmy.
Tymczasowe wyjątki powinny być przyznaniami pierwszej klasy z zakresem, wartością, powodem, wystawcą i wygaśnięciem. Ręczne pole takie jak is_vip jest trudne do interpretacji i zwykle przetrwa pierwotną przyczynę. W przypadku starszych klientów modeluj przypisanie migracyjne z precyzyjnymi regułami i datą przeglądu, zamiast tworzyć trwałe gałęzie kodu.
Zrównoważony wyjątek to audytowalna dana interpretowana przez ten sam resolver; niebezpieczny wyjątek to specjalny warunek dodany do konkretnego przepływu.
Łączenie funkcjonalności, ról i izolacji wielofirmowej
Na platformie wielofirmowej każde zapytanie dotyczące uprawnień, zużycia i konfiguracji musi być ograniczone do właściwej firmy. Nie wyprowadzaj kontekstu wyłącznie z wartości przesłanych przez klienta. Rozstrzygaj go na podstawie uwierzytelnienia, żądanej domeny lub zweryfikowanego kontekstu wewnętrznego i przekazuj go do zadań w kolejce oraz zdarzeń.
Ostateczna decyzja zwykle jest iloczynem logicznym: firma ma funkcjonalność, limit nie został wyczerpany, a aktor ma wymagane uprawnienie. Centralizacja funkcjonalności nie zastępuje modelu ról; zapobiega mieszaniu ról i planów. Rola może przyznawać kto zarządza automatyzacjami, podczas gdy funkcjonalność określa, czy firma może korzystać z automatyzacji.
Dane, audyt i testy pozwalające wyjaśniać decyzje
Przechowuj przypisania uprawnień z okresem ważności i pierwszeństwem, wraz ze zdarzeniami zużycia, gdy agregat nie wystarcza. Rejestruj istotne decyzje: firmę, aktora lub proces, funkcjonalność, ocenioną wartość, wynik, źródło i korelację żądania. Nie zapisuj w tych rejestrach niepotrzebnych danych osobowych i ustanów retencję zgodnie ze swoimi obowiązkami.
Audyt powinien odpowiadać, dlaczego działanie zostało odrzucone, bez konieczności czytania historycznego kodu. Jest szczególnie użyteczny przy zmianach handlowych, incydentach rozliczeniowych i działaniach wsparcia technicznego.
Testy muszą obejmować macierz funkcjonalności i wartości, limity na dokładnej granicy, współbieżność, zmiany planu, wygaśnięcie wyjątków i ponowne próby zdarzeń. Wykonuj te same przypadki przez HTTP, API i workery kolejek, gdy współdzielą przypadek użycia. Dodaj testy izolacji, aby potwierdzić, że jedna firma nie może sprawdzać ani wykorzystywać uprawnień innej.
Stopniowy plan centralizacji istniejącej platformy PHP
- Sporządź inwentaryzację nazw planów, warunków, liczników i ręcznych wyjątków w kodzie oraz operacjach.
- Wybierz funkcjonalność lub limit o dużym wpływie i zdefiniuj jego pełną semantykę przed migracją.
- Wprowadź resolver jako fasadę, początkowo zgodną z obecnymi źródłami.
- Przenieś punkty stosowania do centralnego przypadku użycia, a nie tylko do interfejsu.
- Rejestruj decyzje i porównuj nowe zachowanie z poprzednim przed usunięciem starych gałęzi.
- Migruj plan po planie do jawnych przypisań i usuń odniesienia handlowe z domeny.
Lista kontrolna przed opublikowaniem zmiany
- Czy funkcjonalność ma stabilny identyfikator i jednoznaczną definicję biznesową?
- Czy limit określa jednostkę, zakres, okres, współbieżność i reakcję na przekroczenie?
- Czy reguła jest stosowana na serwerze, w API i procesach asynchronicznych?
- Czy role, funkcjonalności i kontekst firmy są walidowane oddzielnie?
- Czy zmiany planu i wyjątki mają okres ważności, pochodzenie i audyt?
- Czy istnieją testy dla granicy limitu, cofnięcia uprawnienia i izolacji wielofirmowej?
Dzięki temu modelowi katalog handlowy może ewoluować bez przekształcania każdej modyfikacji w poszukiwanie warunków. Platforma zachowuje zrozumiałe, mierzalne i uzasadnialne reguły zarówno dla produktu, jak i inżynierii.
