Ressourceneigentum in einem SaaS: Person, Organisation oder Arbeitsbereich

In einem SaaS, in dem eine Person in mehreren Organisationen oder Arbeitsbereichen arbeiten kann, beantwortet „Wer hat diese Ressource erstellt?“ nicht unbedingt die Frage „Wem gehört sie?“. Dieser Unterschied wirkt sich darauf aus, wer die Ressource sehen, ändern, übertragen oder behalten kann, wenn jemand ein Team verlässt. Wird diese Frage erst spät geklärt, sind die Regeln oft über Abfragen, Controller und Hintergrundaufgaben verstreut.

Das Ressourceneigentum in einem SaaS mit mehreren Benutzern ist eine Domänenentscheidung: Sie legt fest, welche Entität die primäre Beziehung zu einer Ressource hat und welche Folgen diese Beziehung mit sich bringt. Es ist weder gleichbedeutend mit Authentifizierung noch mit Mitgliedschaft oder Berechtigungen. Eine explizite Modellierung sorgt dafür, dass Produkt, Daten und Code einer einheitlichen Regel folgen.

Identität, Zugehörigkeit und Eigentum sind unterschiedliche Beziehungen

Ein Benutzer repräsentiert eine Identität, die sich anmelden kann. Eine Mitgliedschaft drückt aus, dass diese Identität an einer Organisation oder einem Arbeitsbereich beteiligt ist, gegebenenfalls mit einer Rolle oder einem Status. Das Eigentum legt fest, welche Entität gemäß den Produktregeln für eine Ressource verantwortlich ist. Eine Person kann mehreren Arbeitsbereichen angehören und zugleich ein Dokument erstellen, das einem dieser Bereiche gehört.

Auch die Urheberschaft sollte davon getrennt werden. Das Feld created_by kann festhalten, wer die ursprüngliche Aktion ausgeführt hat, sollte aber nicht allein über das Eigentum entscheiden. Verlässt die Person, die den Datensatz erstellt hat, die Organisation, kann die Ressource weiterhin dieser Organisation gehören. Umgekehrt kann eine Person eine Ressource übernehmen, die ursprünglich von jemand anderem erstellt wurde.

Es ist sinnvoll, die Antworten auf drei Fragen zu dokumentieren: Wem gehört die Ressource, wer darf mit ihr arbeiten und wer hat welche relevante Aktion ausgeführt? Soll dasselbe Feld oder dieselbe Beziehung alle drei Fragen beantworten, vermischt das Modell wahrscheinlich unterschiedliche Konzepte.

Zwischen persönlichem, organisatorischem oder gemeinsamem Eigentum wählen

• Persönlich: Die Ressource gehört einem Benutzer. Das ist sinnvoll, wenn ihr Lebenszyklus an diese Person und nicht an ein Team gebunden ist, etwa bei einer privaten Einstellung. Es muss festgelegt werden, was geschieht, wenn das Konto deaktiviert oder gelöscht wird.
• Organisatorisch: Die Ressource gehört einer Organisation oder einem Arbeitsbereich. Das ist geeignet, wenn die Ressource dem Team auch dann weiter zur Verfügung stehen soll, wenn sich dessen Mitglieder ändern. Die Mitgliedschaft des Benutzers ermöglicht den Zugriff, macht ihn aber nicht zum individuellen Eigentümer.
• Gemeinsam: Mehrere Entitäten können eine Eigentums- oder Verantwortungsbeziehung haben. Verwende diese Variante nur, wenn die Domäne tatsächlich Miteigentum erfordert. Sollen mehrere Personen die Ressource lediglich einsehen oder bearbeiten können, handelt es sich normalerweise um Zugriff über Mitgliedschaften oder Berechtigungen und nicht um mehrere Eigentümer.

Die Entscheidung sollte sich nach dem Lebenszyklus der Ressource und den Geschäftsregeln richten, nicht nach dem Wunsch, eine Tabelle zu vereinfachen. Frage, wer die Ressource behalten, über ihre Löschung entscheiden und bei einem Teamwechsel für sie verantwortlich sein kann. Unterscheide außerdem zwischen „Arbeitsbereich“ und „Organisation“: Ist der Arbeitsbereich eine echte Untergliederung mit eigenem Lebenszyklus und eigenen Grenzen, kann er der passende Eigentümer sein. Ist er nur eine Ansicht oder ein Navigationskontext, ist er es möglicherweise nicht.

Die Domäne abbilden, ohne den Eigentümer abzuleiten

In einem einfachen Modell kann eine Ressourcentabelle einen expliziten Eigentümer haben, zum Beispiel über owner_type und owner_id, oder über getrennte Referenzen wie user_id und organization_id. Die erste Option kann mehrere Eigentümertypen erleichtern, erfordert jedoch eine Validierung der Referenzen und die Berücksichtigung der Einschränkungen der referenziellen Integrität bei polymorphen Beziehungen. Getrennte Referenzen machen die Verknüpfungen expliziter, erfordern aber, dass ungültige Kombinationen verhindert werden.

Eine weitere Möglichkeit ist eine gemeinsame Entität, beispielsweise workspace, wenn die Domäne tatsächlich sowohl persönliche Konten als auch Teams darunter abbildet. Führe sie nicht nur ein, um Unterschiede zu verbergen: Sie muss eine klare Bedeutung und stabile Regeln haben. Lege bei jedem Entwurf Einschränkungen fest, die verhindern, dass eine Ressource gleichzeitig inkompatiblen Eigentümern oder – wenn Eigentum erforderlich ist – gar keinem Eigentümer zugeordnet wird.

Modelliere Mitgliedschaften separat, zum Beispiel über eine Beziehung zwischen Benutzer und Organisation, die Status und Rolle umfasst. Der aktive Kontext der Benutzeroberfläche kann anzeigen, in welchem Bereich die Person gerade arbeitet, ist aber keine ausreichende Autorität: Er muss bei jeder Operation validiert werden. Ebenso darf der Eigentümer nicht als „die Person, die die Ressource erstellt hat“ oder als „die aktuell ausgewählte Organisation“ berechnet werden.

Eigentum bei Lese- und Schreibzugriffen sowie automatisierten Prozessen anwenden

Abfragen müssen den Eigentumsbereich und eine geeignete Zugriffskontrolle berücksichtigen. Es reicht nicht, eine Ressource anhand ihrer ID zu laden und darauf zu vertrauen, dass die Benutzeroberfläche nicht zutreffende Ressourcen ausblendet. Zentralisiere in einer PHP-Anwendung die Auflösung des Kontexts und die Autorisierungsregeln in einer wiederverwendbaren Schicht, anstatt unvollständige Bedingungen in jedem Controller zu duplizieren.

Bei Schreibvorgängen müssen der zulässige Eigentümer und die aktuelle Mitgliedschaft des handelnden Benutzers validiert werden. Prüfe außerdem, ob zugehörige Ressourcen – beispielsweise ein Zielordner – zu einem kompatiblen Bereich gehören; andernfalls kann eine Aktualisierung bereichsübergreifende Verknüpfungen erzeugen. Trenne bei administrativen Vorgängen die Ausnahmeautorisierung ausdrücklich von den üblichen Regeln und protokolliere, wer sie aus welchem Grund ausgeführt hat.

Warteschlangen, geplante Befehle, Webhooks und Importe haben nicht immer einen interaktiven Benutzer. Sie müssen eine validierte Eigentümer- oder Kontext-ID mitführen, statt sich auf eine implizite Sitzung zu verlassen. Der Prozess muss dieselben Bereichsregeln wie die Webanwendung anwenden. Arbeitet er mit erweiterten Berechtigungen, müssen diese beschränkt und protokolliert werden.

Die Übertragung als Domänenoperation behandeln

Der Wechsel des Eigentümers sollte keine allgemeine Änderung eines Feldes sein. Definiere Vorbedingungen: Wer darf die Übertragung einleiten, welche Beziehung muss der Empfänger zum Bereich haben und was geschieht bei einer ausstehenden Einladung oder einem inaktiven Konto? Aktualisiert der Vorgang mehrere Beziehungen und damit verbundene Auswirkungen, sollte er atomar sein.

Lege außerdem fest, was mit Abhängigkeiten wie Dateien, Integrationen, Abrechnung oder Automatisierungen geschieht. Gehe nicht davon aus, dass alles zusammen mit der Ressource verschoben werden muss: Diese Richtlinie hängt vom Produkt ab. Können nicht alle Änderungen in einer Transaktion abgeschlossen werden, entwirf einen wiederherstellbaren Prozess mit klaren Zuständen und Idempotenz für Wiederholungsversuche.

Führe gegebenenfalls ein Auditprotokoll mit handelnder Person, bisherigem Eigentümer, neuem Eigentümer, Zeitpunkt und Grund. So lässt sich unterscheiden, wer die Änderung autorisiert und wer die technische Aktion ausgeführt hat. Die ursprüngliche Urheberschaft kann unverändert erhalten bleiben, auch wenn das Eigentum wechselt.

Grenzfälle testen, die Modellierungsfehler aufdecken

Automatisiere Service- und Integrationstests, um sowohl erlaubte als auch verweigerte Zugriffe zu überprüfen. Eine nützliche Testmatrix umfasst eine Person in zwei Organisationen, eigene und fremde Ressourcen in beiden, ausgesetzte oder widerrufene Mitgliedschaften, eine Übertragung an ein nicht berechtigtes Ziel sowie den Zugriff über bekannte IDs. Prüfe sowohl die Antworten als auch die Auswirkungen auf die Daten; eine ausgeblendete Schaltfläche ist kein Autorisierungstest.

Teste auch Ressourcen ohne gültigen Eigentümer, doppelte Beziehungen und Fehler während einer Übertragung. Wenn das Schema einen Eigentümer voraussetzt, sollten Datenbankbeschränkungen diese Erwartung absichern, und Migrationen sollten inkonsistente historische Datensätze erkennen, bevor die Beschränkungen hinzugefügt werden. Prüfe bei Hintergrundaufgaben, ob der Kontext erhalten bleibt und ein erneuter Versuch keine Änderungen dupliziert.

Checkliste vor dem Ausbau des SaaS

• Ist für jeden Ressourcentyp festgelegt, ob er einer Person, einer Organisation oder einem Arbeitsbereich gehört?
• Werden Eigentum, Urheberschaft, Mitgliedschaft, Rolle und aktiver Kontext voneinander unterschieden?
• Validieren Lese- und Schreibabfragen den Eigentümer und die aktuelle Mitgliedschaft?
• Erhalten automatisierte Aufgaben einen expliziten Bereich und wenden gleichwertige Kontrollen an?
• Hat die Übertragung definierte Vorbedingungen und Auswirkungen, eine Auditierung und eine Wiederherstellungsstrategie?
• Gibt es Tests für Benutzer mit mehreren Arbeitsbereichen, Austritte, bereichsübergreifende Zugriffe und inkonsistente Daten?

Hängt eine Antwort von undokumentierten Konventionen ab, sollte sie geklärt werden, bevor weitere Ressourcentypen oder Kollaborationsabläufe hinzukommen. Ein explizites Modell beseitigt nicht alle komplexen Fälle, macht die Entscheidungen aber sichtbar und ermöglicht ihre Überprüfung im Schema, in den Abfragen und in den Tests.