Trennung
Die Grenze, die die Datenbank hält, nicht der Code
Jedes CRM behauptet, mandantenfähig zu sein. Die Behauptung ist billig; entscheidend ist, welche Schicht die Linie hält. Wenn die Antwort lautet „unsere Anwendung fügt immer den richtigen Filter hinzu“, dann ist die Garantie nur so gut wie der am wenigsten ausgeschlafene Entwickler, der je eine Abfrage geschrieben hat.
iKonekt war ab seiner ersten Migration mandantenfähig statt nachträglich umgerüstet — das klingt nach Prahlerei und ist in Wahrheit ein Geständnis: Nachrüsten ist kaum überzeugend möglich, und jeder, der es versucht hat, hat eine Geschichte dazu.
Die Trennung lebt in der Datenbank. Jede der sechsundzwanzig Tabellen trägt den Mandanten, zu dem sie gehört, und die Richtlinie, die das prüft, läuft bei jedem Lese- und jedem Schreibvorgang, vollständig unterhalb der Anwendung. Eine Abfrage, die die Grenze vergisst, gibt nicht die Kunden eines anderen zurück. Sie gibt nichts zurück.
Sicherheit auf Zeilenebene, erzwungen
Keine Konvention, keine Code-Review-Regel. Die Datenbank verweigert es. Zweiundsiebzig Richtlinien, einzeln ausgeschrieben statt generiert — denn eine generierte Richtlinie ist eine Richtlinie, die niemand gelesen hat.
Zusammengesetzte Schlüssel
Ein Kind-Datensatz referenziert seinen Mandanten und sein Elternelement gemeinsam, als Paar. Eine fremde Kennung aus dem falschen Unternehmen löst sich nicht auf — sie ist schlicht keine gültige Referenz.
Kein Standardmandant, niemals
Eine Anfrage ohne Bereich wird nicht stillschweigend zu einer Anfrage an Mandant null. Sie wirft einen Fehler, bevor sie die Datenbank erreicht. Es gibt keinen „unscoped“-Modus, den man vergessen könnte auszuschalten.
Der Fehler, der sich nicht melden konnte
Während der Mandanten-Arbeit waren die meisten Fehler laut. Gibt man zwei Unternehmen dieselbe Kundendomain, meldeten sich die Datenbankobjekte sofort mit Fehlercode und Stack-Trace; man behebt es vor dem Mittagessen.
Ein Fehler widersprach nicht. Eine Tabelle bearbeitbarer Prompt-Overrides war allein nach der Art des Prompts verschlüsselt — nicht nach Art und Mandant. Hätte ein zweites Unternehmen seine eigene Kopie bearbeitet, hätte es still die des ersten überschrieben — durch völlig gültiges SQL, ohne Fehler, ohne Warnung und ohne fehlgeschlagenen Test. Gefunden wurde es, indem nach der Änderung eines Schlüssels jeder verbleibende Unique-Index einzeln gelesen wurde, im Verdacht, dass die lauten Fehler Gesellschaft hatten.
Wir erwähnen es, weil es die ehrliche Gestalt dieser Arbeit ist. Trennung ist keine Funktion, die man einschaltet; sie ist eine Gewohnheit, die langweiligen Teile des Schemas zu lesen, in der Annahme, dass etwas darin anderer Meinung ist.
Die Tests, der Vollständigkeit halber: 942 Stück, ausgeführt gegen eine Datenbank, die bei jeder Änderung von null neu aufgebaut wird. Sie sind nicht da, um zu beweisen, dass das Design clever ist. Sie sind da, weil das Fehlermuster dieses speziellen Designs stumm ist — und stumme Fehler brauchen jemanden, der für sie schreit.
Was Trennung einem normalen Menschen bringt
- Eine Gruppe kann mehrere Unternehmen aus einer Installation betreiben, und ein Verkäufer im einen sieht niemals einen Kunden des anderen — nicht durch Richtlinie, sondern durch Konstruktion.
- Ein Partnerprogramm, ein Satz Prompts, ein Anspruch auf einen Kunden: alles pro Unternehmen abgegrenzt, sodass die Konfiguration eines Mandanten nicht zur aller werden kann.
- Ein Löschantrag wird innerhalb einer Grenze statt über einen gemeinsamen Haufen erledigt — genau das macht es möglich, ehrlich zu antworten.
- Und niemand muss sich daran erinnern. Das ist der Punkt — eine Garantie, die davon abhängt, dass man sich erinnert, ist keine Garantie.
Noch eine Zeile, die nicht über Datenbanken handelt
Jeder Geschwisterdienst in der Familie hält seinen eigenen benannten Berechtigungsnachweis. Nichts spricht mit einem gemeinsamen, sodass kein Dienst versehentlich als ein anderer handeln kann — eine kleine Disziplin, die direkt daher stammt, dass wir einmal ein gemeinsames Token hatten und das nicht genossen haben.
Es ist derselbe Instinkt wie die Datenbankregel. Machen Sie das Falsche unmöglich statt nur missbilligt, dann wenden Sie Ihre Aufmerksamkeit Kunden statt Wachsamkeit zu.
- 126 TabellenJede trägt ihren Mandanten, mit erzwungener Prüfung.
- 272 RichtlinienEinzeln ausgeschrieben, sodass jede von einem Menschen gelesen wurde.
- 3942 TestsGegen eine Datenbank, die bei jeder Änderung von null neu aufgebaut wird.
- 40 Standard-MandantenEine Anfrage ohne Geltungsbereich erreicht die Daten nie.
Gemessen am Live-Build
„Unsere Anwendung filtert immer nach Unternehmen.“
Das „immer“ leistet in diesem Satz eine Menge Arbeit.
Verlagert man die Grenze hinunter in die Datenbank, liefert eine vergessene WHERE-Klausel nichts statt der Kunden eines anderen zurück. Ein leerer Bildschirm ist ein besserer Fehler als eine unangenehme Vorstellung.
Für Gruppen mit mehreren Marken →