Mogelijkheden en limieten in een PHP-SaaS zonder plancondities

Wanneer de logica van een SaaS begint met voorwaarden zoals if ($tenant->plan === 'pro'), lijkt dat een directe oplossing. Het probleem ontstaat bij de tweede cataloguswijziging: een plan krijgt een andere naam, een mogelijkheid wordt afzonderlijk verkocht, een klant behoudt oude voorwaarden of support moet tijdelijk iets inschakelen. Dan beschrijft de commerciële naam niet langer een stabiele regel en raakt deze verspreid over controllers, geplande taken, query's, API en interface.

Mogelijkhedenbeheer in PHP-SaaS moet het commerciële aanbod vertalen naar verifieerbare domeinbeslissingen. De code zou niet moeten vragen of een bedrijf “Pro” is, maar of het een concrete actie mag uitvoeren, met welke limiet, onder welke voorwaarden en tot wanneer. Deze scheiding maakt het mogelijk om prijzen of bundelingen te wijzigen zonder operationele regels te herschrijven.

Plan, mogelijkheid, limiet, permissie en configuratie scheiden

Deze concepten hangen samen, maar zijn niet onderling uitwisselbaar. Een plan is een commerciële bundeling. Een mogelijkheid schakelt een productmogelijkheid in, zoals gegevens exporteren, automatiseringen maken of een integratie gebruiken. Een limiet definieert een toegestane hoeveelheid of snelheid, bijvoorbeeld actieve projecten, factureerbare gebruikers of API-verzoeken per periode.

Een permissie beantwoordt een andere vraag: welke identiteit mag binnen een bedrijf een actie uitvoeren. Dat een organisatie de mogelijkheid heeft om gegevens te exporteren, betekent niet dat elke gebruiker die mag exporteren. Tot slot bestaat klantconfiguratie uit opties die geldig zijn voor een concreet bedrijf, zoals de gekozen identiteitsprovider, een retentiebeleid of een notificatiesjabloon. Gebruik geen vrije configuratie om commerciële of autorisatiebeslissingen te verbergen.

• Plan: commerciële samenstelling van rechten en limieten.
• Mogelijkheid: functionele regel uitgedrukt in producttermen.
• Limiet: kwantificeerbare drempel gekoppeld aan een mogelijkheid of resource.
• Permissie: autorisatie van een actor om een actie uit te voeren.
• Configuratie: gedragsparameter die beschikbaar is binnen de reeds toegekende regels.

Een beslissing kan alle lagen vereisen. Om een automatisering te maken, heeft het bedrijf de bijbehorende mogelijkheid nodig, moet het onder de limiet voor actieve automatiseringen blijven en moet de gebruiker een beheerpermissie hebben. Daarna kan de flow de doelconfiguratie valideren.

Domeinregels modelleren, geen plannamen

Hanteer een stabiele catalogus van mogelijkheden met technische identifiers die onafhankelijk zijn van marketing: automation.create, data.export of api.webhooks. De catalogus kan het verwachte waardetype bevatten: boolean, geheel getal, optieset of gestructureerd beleid. De identifier drukt een productbehoefte uit; deze mag geen plannaam of campagne bevatten.

De commerciële toewijzing kan in een afzonderlijke laag worden opgelost. Een huidig plan levert een set toekenningen op, maar er kunnen ook add-ons, legacy-migraties en expliciete uitzonderingen bestaan. Het resultaat voor elk bedrijf is een oplossing van effectieve rechten met herkomst.

mogelijkheid: automation.create
werkelijke waarde: true
herkomst: add-on voor automatiseringen
geldigheid: tot annulering

Deze herkomst is essentieel. Als een mogelijkheid actief is, moeten product, support en facturatie weten of die voortkomt uit het huidige plan, een legacyclausule of een uitzondering met vervaldatum. Vermijd om alleen een veld plan bij het bedrijf op te slaan en al het overige bij elk gebruikspunt af te leiden.

Eén centrale beslissingsservice

Stel in PHP een domeinservice beschikbaar, bijvoorbeeld EntitlementResolver of CapabilityGate, die het bedrijf, de mogelijkheid en de benodigde context ontvangt. Deze moet een uitlegbare beslissing retourneren, niet alleen een boolean: toegestaan of afgewezen, opgeloste waarde, reden, bronregel en evaluatiedatum. Deze datum vertegenwoordigt het moment waarop de resolver de beslissing vaststelde en maakt het mogelijk om geldigheidsduren, vervaldata en latere planwijzigingen correct te interpreteren. Controllers, commands, listeners en asynchrone workers raadplegen deze service; zij bouwen niet hun eigen subscription-query's opnieuw op.

Meetbare limieten definiëren voordat u ze programmeert

Een dubbelzinnige limiet leidt tot conflicten en implementatiefouten. “Tot 100 gebruikers” vereist een antwoord op de vraag wat als gebruiker telt: een wachtende uitnodiging, een opgeschorte gebruiker, een lid dat tijdens de cyclus is verwijderd, een serviceaccount? “Duizend exports” vereist een definitie van de periode, tijdzone, retries en of een mislukte export quota verbruikt.

Documenteer voor elke limiet ten minste:

• De resource, gebeurtenis of het verbruik dat wordt geteld.
• De scope: bedrijf, project, gebruiker of integratie.
• Het venster: totale geldigheidsduur, kalenderdag, factureringsmaand of rolling window.
• Het controlemoment: vóór het aanmaken, bij activering, bij verzending of na consolidatie.
• De reactie: blokkeren, toestaan met waarschuwing, in een wachtrij plaatsen, degraderen of goedkeuring vereisen.
• De afhandeling van concurrency, retries, annuleringen en reversie.

Limieten voor actieve objecten worden doorgaans gevalideerd met een transactionele operatie of een reservering die voorkomt dat de drempel bij concurrency wordt overschreden. Verbruikslimieten hebben een teller met duidelijke semantiek en idempotentie via een event key nodig. Vertrouw niet alleen op een teller die in de interface wordt getoond: twee gelijktijdige verzoeken kunnen allebei een voorafgaande controle passeren en het maximum overschrijden.

Maak ook onderscheid tussen waarschuwing en blokkering. Een melding bij 80% verbetert de voorspelbaarheid, maar vervangt geen echte bescherming op het punt waar de resource wordt aangemaakt of uitgevoerd.

De regels op alle uitvoerpaden toepassen

Een knop verbergen is een verbetering van de gebruikerservaring, geen toegangscontrole. De validatie moet bestaan in de server-side use case die de actie uitvoert. Zo dekt u de webinterface, publieke API, integraties en interne aanroepen.

Asynchrone processen vereisen een extra beslissing: controleer bij het in de wachtrij plaatsen en controleer opnieuw bij uitvoering wanneer de taak vertraging kan oplopen. Als een bedrijf tussen die twee momenten een mogelijkheid verliest, moet het beleid bepalen of de taak wordt geannuleerd, wordt voltooid omdat deze eerder werd geaccepteerd, of beoordeling vereist. De keuze hangt af van het type operatie, maar moet consistent en vastgelegd zijn.

Support- en beheertools mogen de regels niet stilzwijgend omzeilen. Ze kunnen werken met een andere administratieve autorisatie, maar moeten traceerbaarheid achterlaten en aangeven of ze een formele toekenning, een gegevenscorrectie of een uitzonderlijke actie opleveren.

Wijzigingen, legacyrechten en uitzonderingen beheren zonder het product af te splitsen

Een planwijziging is niet alleen het bijwerken van een label. Deze kan een limiet onder het huidige gebruik verlagen of een mogelijkheid intrekken die actieve processen ondersteunt. Definieer beleid per resourcetype: nieuwe creaties verhinderen en het bestaande behouden, overschrijdingen expliciet deactiveren, een overgangsperiode geven of de bedrijfsbeheerder om een keuze vragen.

Tijdelijke uitzonderingen moeten eersteklas toekenningen zijn met scope, waarde, reden, verstrekker en vervaldatum. Een handmatig veld zoals is_vip is moeilijk te interpreteren en overleeft vaak de oorspronkelijke oorzaak. Modelleer voor legacyklanten een migratietoewijzing met precieze regels en een herzieningsdatum, in plaats van permanente vertakkingen in de code te creëren.

Een duurzame uitzondering is controleerbare data die dezelfde resolver interpreteert; een gevaarlijke uitzondering is een speciale conditie die aan een concrete flow is toegevoegd.

Mogelijkheden, rollen en isolatie tussen bedrijven combineren

In een platform voor meerdere bedrijven moet elke query naar rechten, verbruik en configuratie worden afgebakend door het juiste bedrijf. Leid de context niet uitsluitend af uit waarden die door de client zijn verzonden. Los deze op vanuit de authenticatie, het aangevraagde domein of de gevalideerde interne context, en propageer deze naar queued jobs en events.

De uiteindelijke beslissing is doorgaans een doorsnede: het bedrijf beschikt over de mogelijkheid, de limiet is niet bereikt en de actor heeft de vereiste permissie. Mogelijkheden centraliseren vervangt geen rollenmodel; het voorkomt dat rollen en plannen door elkaar raken. Een rol kan bepalen wie automatiseringen beheert, terwijl de mogelijkheid bepaalt of het bedrijf automatiseringen kan gebruiken.

Data, audits en tests om beslissingen uit te leggen

Bewaar rechtentoewijzingen met geldigheid en prioriteit, samen met verbruiksgebeurtenissen wanneer een aggregaat niet volstaat. Registreer relevante beslissingen: bedrijf, actor of proces, mogelijkheid, geëvalueerde waarde, resultaat, bron en requestcorrelatie. Bewaar geen onnodige persoonsgegevens in deze registraties en stel retentie in volgens uw verplichtingen.

De audit moet kunnen beantwoorden waarom een actie is afgewezen zonder dat historische code gelezen hoeft te worden. Dit is vooral nuttig bij commerciële wijzigingen, factureringsincidenten en supportwerkzaamheden.

Tests moeten een matrix van mogelijkheden en waarden omvatten, limieten op de exacte grens, concurrency, planwijzigingen, het vervallen van uitzonderingen en event-retries. Voer dezelfde scenario's uit via HTTP, API en queue workers wanneer ze dezelfde use case delen. Voeg isolatietests toe om te bevestigen dat een bedrijf geen rechten van een ander bedrijf kan raadplegen of verbruiken.

Geleidelijk plan om een bestaand PHP-platform te centraliseren

1. Inventariseer plannamen, condities, tellers en handmatige uitzonderingen in de code en de operatie.
2. Kies een mogelijkheid of limiet met grote impact en definieer de volledige semantiek voordat u deze migreert.
3. Introduceer de resolver als façade, aanvankelijk compatibel met de huidige bronnen.
4. Verplaats de toepassingspunten naar de centrale use case, niet alleen naar de interface.
5. Registreer beslissingen en vergelijk het nieuwe gedrag met het oude voordat u oude vertakkingen verwijdert.
6. Migreer plan voor plan naar expliciete toewijzingen en verwijder commerciële verwijzingen uit het domein.

Checklist voordat u een wijziging publiceert

• Heeft de mogelijkheid een stabiele identifier en een ondubbelzinnige zakelijke definitie?
• Specificeert de limiet eenheid, scope, periode, concurrency en reactie op overschrijding?
• Wordt de regel toegepast op de server, in de API en in asynchrone processen?
• Worden rollen, mogelijkheden en bedrijfscontext afzonderlijk gevalideerd?
• Hebben planwijzigingen en uitzonderingen geldigheid, herkomst en audit?
• Bestaan er tests voor de limietgrens, intrekking en isolatie tussen bedrijven?

Met dit model kan de commerciële catalogus evolueren zonder dat elke wijziging verandert in een zoektocht naar condities. Het platform behoudt begrijpelijke, meetbare en verdedigbare regels voor zowel product als engineering.