Das Abschlussprojekt von K4 hat ein Ziel: Die Kladde dient mehreren Büros. Bisher arbeitet in ihr genau ein erfundenes IT-Büro. Am Ende dieses Moduls arbeiten mehrere erfundene Büros darin, jedes sieht nur seine eigenen Daten, die Kladde läuft so in Azure, wie es Ihr ADR zum Mandantenmodell aus Lektion 4.7.6 festgelegt hat, und Sie können jede dieser Aussagen beweisen.

Das Modul hat keine eigene Zwischenaufgabe. Das Abschlussprojekt führt die ganze Stufe zusammen: Eine Person aus Ihrem Kreis prüft Ihre Arbeit im Review (4.9.6), und Sie prüfen sie selbst mit einer Checkliste im Architektur-Review (4.9.7). Bis dahin gehen Sie diese Schritte:

Lektion Was entsteht
4.9.1 Planen Issues mit Abnahmekriterien, Meilensteine, ein Machbarkeitsnachweis für das größte Risiko
4.9.2 Mandanten anlegen und auflösen Büros im Kontext Mandanten, das Büro jeder Anfrage aus dem Token, Sperren und Entfernen
4.9.3 Isolation beweisen eine Testreihe, die jede Lese- und Schreibstelle mit einem fremden Büro angreift
4.9.4 Ausliefern und betreiben die Kladde mandantenfähig in Azure, Verteilen in Ringen, eine Notfallprobe für ein Büro, Kosten je Büro
4.9.5 Architekturdokumentation docs/ vollständig und aktuell zum Code
4.9.6 Architektur-Review ein Review der Arbeit einer anderen Person und Antworten auf das eigene
4.9.7 Architektur-Review mit Checkliste Demo, Code-Lesung und Fragen über K4 hinweg, geprüft gegen eine Checkliste

In dieser Lektion planen Sie. Das klingt nach dem leichtesten Teil, ist aber der, an dem Projekte am häufigsten scheitern: nicht an schwerem Code, sondern daran, dass das schwerste Problem erst in der letzten Woche auftaucht.

Wo die Kladde jetzt steht

Bevor Sie planen, was noch fehlt, schreiben Sie auf, was schon da ist. In K4 ist bis hierher in jedem Modul etwas dazugekommen, das die Mandantenfähigkeit vorbereitet hat:

Modul Was schon da ist
4.1 Qualitätsziele mit „mehrere Büros in einer Kladde“, ADRs, C4-Kontext und -Container, die Kostenrechnung mit der Kennzahl „Kosten je Büro“
4.2 der Kontext Mandanten (Tenants) mit Büro, Mitarbeitenden und Rollen, die Datenhoheit je Kontext
4.3 TenantId im Shared Kernel, in jedem Aggregat und jedem Speicherschlüssel; ICurrentUser liest das Büro aus dem Token; der Architekturtest
4.4 der Event Store mit der Spalte TenantId und dem eindeutigen Schlüssel auf Büro, Stream und Version; Lesemodelle mit TenantId
4.5 Grains mit dem Schlüssel {tenant}/{id}, ein Cluster mit zwei Silos in Container Apps
4.6 Outbox, Inbox, der Prozess „Angebot angenommen“, der Anti-Corruption Layer für TED
4.8 Bedrohungsmodell, Schwärzung in Logs, Löschung und Auskunft für Kontakte, die Rechtetabelle
4.7 Netz und Governance in Bicep, die Anmeldung aus mehreren Entra-Verzeichnissen, eine Notfallprobe, das ADR zum Mandantenmodell
4.10 bis 4.14 die ADRs zur Code-Architektur und zur Datenarchitektur, je nach Ihrem Weg ein eigener Dienst für die Ausschreibungen (4.12), die Schätzung aus 4.14.2

Was fehlt, ist der Teil, der aus „jeder Schlüssel trägt ein Büro“ ein echtes Mehr-Büro-System macht:

  • Bisher ist das Büro das Entra-Verzeichnis. ICurrentUser liest seit 4.3.5 die Verzeichnis-Id tid aus dem Token und nimmt sie direkt als TenantId. Wer sich aus irgendeinem Verzeichnis anmelden darf, hätte damit ein eigenes Büro. Es fehlt ein Verzeichnis der Büros, das sagt, welche Verzeichnisse zu welchem Büro gehören und ob das Büro gerade arbeiten darf.
  • Niemand hat bewiesen, dass die Mandanten-Id überall wirkt. Sie steht in den Schlüsseln. Ob jede Abfrage, jedes Lesemodell, jede Suche und jeder Export sie auch benutzt, hat noch kein Test für alle Stellen geprüft.
  • Betrieb je Büro gibt es nicht. Ein Büro sperren, entfernen, aus einer Sicherung holen, seine Kosten messen: Das ist noch nie geschehen.

Wenn Sie in Lektion 4.14.2 den Aufwand der Mandantenfähigkeit als Bandbreite geschätzt haben, legen Sie diese Schätzung jetzt neben den Plan. Am Ende des Moduls vergleichen Sie sie mit dem, was es wirklich gekostet hat.