69 Regelwerke, die vor dem ersten Tag schon gelten.
Die ehrliche Erklärung für das Tempo ist nicht der Agent. Sie ist das, was vor dem ersten Tag schon entschieden ist — von Clean Code über den Dienstschnitt bis zur Mandantentrennung. Jedes dieser Regelwerke hat einen Schlüssel, unter dem es nachgeschlagen wird. Dazu kommen die neun Regeln für agentische Arbeit und die sieben für Betrieb.
Das Produkt erbt die Regeln, es kopiert sie nicht.Jeder Prototyp verlinkt die gemeinsamen Regelwerke. Ändert sich eine Regel, gilt sie auch dort — statt als veraltete Kopie liegen zu bleiben. Deshalb kann diese Liste wachsen, ohne dass irgendwo nachgezogen werden muss.
3 Regelwerke
Grundsätze
Was innerhalb eines Schnitts gilt — unabhängig von Sprache und Baustelle.
| Software-Engineering-Prinzipien | SOLID, Clean Code, ein einheitliches Fehlerprinzip und eine festgelegte Haltung zur Code-Review. |
| Naming & Code-Organisation | Sprachunabhängige Konventionen für Benennung und Dateiaufbau, samt einer Liste ausdrücklich unerwünschter Muster. |
| Domänensprache in Bezeichnern | Ein Bezeichner trägt den Fachbegriff, nicht eine technische Umschreibung davon. |
8 Regelwerke
Schnitt & Betrieb
Wo die Grenzen zwischen Diensten liegen — und wer sie ziehen darf.
| Architekturübersicht | Drei gleichrangige Säulen: Dienste, Oberfläche, Prozesse — jede mit eigener Leitidee. |
| Separation of Concerns im Dienstschnitt | Fachlicher Schnitt nach Domänen statt nach technischen Schichten, technologieunabhängig formuliert. |
| Jeder Dienst besitzt seine Ablage | Kein zentraler Dokumentendienst, keine geteilte Speicherbibliothek. |
| Dienst-Grundausstattung | Fünf Querschnitte trägt jeder Dienst — ausnahmslos, unabhängig von seiner Domäne. |
| Geteilte externe Fähigkeiten | Eine externe Abhängigkeit liegt hinter einem gemeinsamen Zugang, nicht in jedem Dienst einzeln. |
| Zuständigkeit für Rechte | Jedes Produkt benennt die Stelle, die über Fähigkeiten und Rechte entscheidet. |
| Betriebsmuster für mehrere Anwendungen | Wie Plattform und Anwendungen in einem gemeinsamen Betrieb nebeneinanderliegen. |
| Sprachwahl für einen Dienst | Woraus ein betriebener Dienst gebaut sein darf — mit genau zwei benannten Ausnahmen. |
9 Regelwerke
Dienstbausteine
Die wiederkehrenden Probleme jedes Dienstes, einmal entschieden.
| Export, Import, Erstbefüllung | Jeder Dienst kann seine Kerndaten ausgeben und wieder einlesen — die Grundlage jeder Erstbefüllung und jedes Umzugs. |
| Datenhaltung im Dienst | Wie ein Dienst seine Daten legt, sprachunabhängig festgelegt. |
| Fachliche Ereignisse | Ereignisse über Dienstgrenzen hinweg, mit festem Format und fester Namensregel. |
| Nachvollziehbarkeit | Ein Aufruf über mehrere Dienste bleibt vom Eingang bis zur Antwort verfolgbar. |
| Zeitgrenzen und Wiederholung | Was wie lange warten darf und was nicht automatisch wiederholt wird — entschieden statt je Aufruf erfunden. |
| Verteilte Vorgänge | Mehrschrittige Vorgänge ohne gemeinsame Transaktion über Dienstgrenzen. |
| Zwischenspeicher | Wo zwischengespeichert wird — und wo ausdrücklich nicht. |
| Zustellgarantien | Welche Garantie ein Ereignis hat und was der Empfänger deshalb aushalten muss. |
| Wiederkehrende Hintergrundarbeit | In welchem Dienst sie liegt, wie oft sie läuft und wer sie beaufsichtigt. |
5 Regelwerke
Schnittstellen
Die API-Regeln — technologieunabhängig und für jeden Dienst gleich.
| API-Architektur | Ressourcenschnitt, Verben, Statuscodes und Namensformen als eine Konvention für alle Dienste. |
| Fehlerformat | Ein Format für jeden Fehler — die Voraussetzung dafür, dass eine Oberfläche generisch damit umgehen kann. |
| Idempotenz | Ein zweimal gesendeter Aufruf darf nicht zweimal wirken. |
| Versionierung | Die Schnittstellenversion steht im Pfad; ein Wechsel ist sichtbar statt stillschweigend. |
| Langläufer | Was länger als ein paar Sekunden dauert, wird nicht synchron beantwortet. |
11 Regelwerke
Umsetzung
Dieselben Regeln, eine Ebene tiefer: wie sie im Code aussehen.
| Trennung von Modell und Übertragung | Das interne Datenmodell verlässt den Dienst nicht; nach außen gehen eigene Übertragungsobjekte. |
| Auditierbare Entitäten | Änderungsspur und reine Anhänge-Daten als Baustein statt als Fleißarbeit. |
| Ereignisse verlässlich senden | Ereignisse werden mit dem fachlichen Schreibvorgang zusammen festgeschrieben, nicht nebenbei verschickt. |
| Starke Typen | Fachliche Werte bekommen einen eigenen Typ statt als Zeichenkette durchgereicht zu werden. |
| Fehler werfen | Wie ein Fehler entsteht — was der Aufrufer davon sieht, regelt das Fehlerformat. |
| Validierung | Die Schnittstelle prüft die Eingabe, die Fachlogik prüft die Regel. Zwei Orte, zwei Zuständigkeiten. |
| Aufruferkontext | Wer aufruft und für welchen Mandanten — an einer Stelle gelöst, nicht in jedem Endpunkt. |
| Aufrufe zwischen Diensten | Wie ein Dienst einen anderen ruft und was er dabei an Kontext mitgibt. |
| Schlüsselerzeugung | Der Dienst vergibt den Schlüssel, nicht der Aufrufer. |
| Suchen und Blättern | Suche, Filter und seitenweise Ausgabe als eine Umsetzung für alle Ressourcen. |
| Aufzählungstypen | Zwei getrennte Darstellungen: eine zum Speichern, eine zum Anzeigen. |
5 Regelwerke
Prozesse
Der Teil, den die meisten Regelwerke auslassen.
| Microprocess-Architektur | Geschäftsprozesse überschreiten fachliche Grenzen — deshalb ist ihr Schnitt eigens geregelt. |
| BPMN-Modellierung | Benennung, Struktur und Modellierungsmuster — einschließlich der ausdrücklich verbotenen. |
| Aufgaben-Lebenszyklus | Eine Aufgabe wird beansprucht, bevor sie bearbeitet wird. Zwei Bearbeiter derselben Aufgabe sind kein Zufall, sondern ein Fehler. |
| Prozess-Steckbrief | Jeder Prozess hat ein Datenblatt neben seinem Modell — Zweck, Auslöser, Beteiligte, Datenklasse. |
| Mandant im Prozessmotor | Der Mandant wird beim Prozessstart ausdrücklich gesetzt — eine Variable allein reicht nicht, weil sich sonst mehrere Mandanten eine Prozessablage teilen. |
7 Regelwerke
Oberfläche
Damit eine Oberfläche in Stunden entsteht statt in Wochen.
| Oberflächenarchitektur | Wie eine Oberfläche geschnitten wird: Seiten, Zustände, Datenzugriff, Zuständigkeiten. |
| Seitenaufbau | Der verbindliche Aufbau jeder Seite — damit Abweichung auffällt statt sich zu verstecken. |
| Tabellen und Blättern | Listen, Suche und Seitenwechsel als fertige Bausteine statt als Projektarbeit. |
| Anbindung an die Dienste | Wie die Oberfläche Dienste anspricht — einheitlich erzeugt und konfiguriert. |
| Adressen und Routen | Adressen sind Teil der Oberfläche und werden wie sie benannt. |
| Design-System | Typografie und Bedienprimitive kommen aus einer Quelle, samt übersetzbarer Texte. |
| Konventionen der Oberflächentechnik | Die Rahmenkonventionen der eingesetzten Technik — abgegrenzt von der Architekturregel darüber. |
9 Regelwerke
Sicherheit
Neun Regelwerke. Keines davon entsteht im Prototyp.
| Übersicht | Das Sicherheitsbild im Ganzen: welche Schicht wofür zuständig ist. |
| Authentifizierung | Jede Anfrage kommt von einem Akteur — und es gibt genau vier Typen davon. |
| Autorisierung | Rechte als Fähigkeit und Zuweisung, geschnitten nach Domäne, Ressource und Aktion. |
| Agentische Autorisierung | Was ein Agent im eigenen Namen tut und was im Auftrag eines Menschen — sichtbar getrennt, nicht verschmolzen. |
| Mandantentrennung | Kein Weg über eine Schnittstelle führt an die Daten eines anderen Mandanten. |
| Abwehr eingeschleuster Befehle | Schutz auf allen Ebenen, von der Eingabe bis zur Abfrage. |
| Sicherheitsbeobachtung | Zwei Ebenen: Kennzahlen für das Auffällige, ein eigener Kanal für den Zusammenhang. |
| Isolationsstärke je Datenklasse | Welche Trennung reicht, ist je Datenklasse entschieden — nicht pauschal und nicht nach Gefühl. |
| Identität und Zugriff | Wie Anmeldung, Identität und Zugriff zusammenhängen, wenn die Anmeldestelle nicht veränderbar ist. |
3 Regelwerke
Datenschutz & Pflichten
Was nicht verhandelbar ist, steht nicht im Ticket, sondern hier.
| Datenschutz und interne Kennungen | Interne Kennungen verlassen das System nicht — nach außen geht ein eigener Schlüssel. |
| Datenlebenszyklus | Welche Zustände Daten durchlaufen, wie lange sie leben und wann gelöscht wird. |
| Gesetzlich fixierte Quoten | Wo der Gesetzgeber eine feste Quote vorgibt, bildet das System sie ab — statt sie jemanden nachrechnen zu lassen. |
4 Regelwerke
Test
Vier Testarten mit klarer Zuständigkeit — nicht vier Namen für dasselbe.
| Durchgehende Oberflächentests | Lesepfade durch die fertige Oberfläche: ist die Seite da, sind die Daten da. |
| Komponententests | Der wertvollste Test läuft durch den ganzen Stapel bis zur echten Datenbank. |
| Einheitentests | Eine Einheit, isoliert, ohne Umgebung und ohne Fremdabhängigkeit. |
| Verhaltenstests | Fachliches Verhalten als Testfall — formuliert in der Sprache der Fachlichkeit, nicht in der des Codes. |
5 Regelwerke
Projektanlage & Dokumentation
Wie ein Vorhaben beginnt — und was vorliegen muss, bevor es beginnt.
| Regeln für Regeln | Was in welchem Dokumenttyp steht, wie es geschrieben wird, und warum das Pflicht ist. |
| Projektanlage | Wie ein neues Produkt startet: grün gebautes Referenzbeispiel, Architekturprüfung ab dem ersten Tag, verlinkte statt kopierte Regeln. |
| Bauen gegen den lokalen Stand | Wie gebaut wird, wenn die gemeinsamen Bausteine nicht aus einem öffentlichen Verzeichnis kommen. |
| Vorbereitung vor dem Start | Was eingesammelt wird, bevor das erste Modul entsteht — das Minimalset, ohne das kein Sprint beginnt. |
| Use-Case-Extraktion | Vom Rohmaterial zum ersten Entwurf: was belegt ist, wird belegt; was offen ist, bleibt offene Frage. Einen dritten Zustand gibt es nicht. |