Bérlők, a gazda és az adatszűrő
A ToRun az ABP Framework több bérlős modelljére épül. Az IsMultiTenant jelölésű soroknak van egy TenantId oszlopa, amelyre a keretrendszer automatikusan szűr; az egy bérlő kontextusában futó lekérdezések soha nem látják egy másik bérlő sorait. A gazdakontextus (TenantId == null) egy külön szeletet lát: ott élnek a kanonikus katalógusok, például a SubscriptionPlan, az AiProvider és a LegalDocument.
Miért kezeljük a gazdát teljes jogú résztvevőként
A legtöbb SaaS-termék „adminisztrációs eszközként” teszi hozzá a gazdát. Mi testvérbérlőként modellezzük: a gazdának saját irányítópultjai, saját AI-szabályzatai és saját számlázási kapcsolatai vannak. Így a saját éles forgalmunkat ugyanazokon az építőelemeken futtathatjuk, amelyeket minden ügyfél használ.
Csomaghoz kötött funkciók bérlőnként
Az előfizetési csomagok FeatureLimit, Entitlement, Capability és Mode sorokat hordoznak. Amikor egy bérlő aktivál egy csomagot, az elérhető funkcióinak köre a csomagja és a globális katalógus metszete. Egy új mód hozzáadásához nem kell minden bérlőhöz hozzányúlni: automatikusan megkapja, ha a csomagja tartalmazza.
BYOK-befecskendezés minden hívásnál
Megosztott infrastruktúra mellett is a BYOK-hitelesítő adatok a tulajdonos bérlőre korlátozódnak. Minden AI-kérés a bérlő kontextusában, ugyanazzal az adatszűrővel oldja fel a hitelesítő adatokat; a kulcsok bérlők közötti kiszivárgása a tárolási rétegben nem lehetséges.
Amit szándékosan nem csinálunk
A bérlőket nem különítjük el adatbázis- vagy folyamatszinten. A bérlőnkénti külön adatbázis skálázásának költsége tönkreteszi egy több bérlős SaaS-termék egységgazdaságtanát. Az adatszűrő a bérlőnként elkülönített gyorsítótárral együtt elegendő, ha a sémát az első naptól erre tervezik.