Als Schema und Modell auseinanderliefen

Manche Fehler sind groß, weil ihre Ursache groß ist. Andere sind groß, obwohl ihre Ursache winzig ist — und die sind die lehrreicheren. Diese Geschichte handelt von einem solchen. Sie ist bewusst allgemein gehalten — ohne Projekt, ohne Beteiligte, ohne Zeitpunkt.

Situation

In einem großen Vorhaben mit mehreren Teams hielt sich ein Fehler hartnäckig. Er trat auf, ohne sich leicht fassen zu lassen, und widerstand der Suche länger, als seine spätere Erklärung vermuten ließ. Viele Hände arbeiteten am selben System, und der Fehler betraf einen Bereich, den mehrere berührten.

Ausgangsannahmen

Ein hartnäckiger Fehler in einem großen System weckt die Erwartung einer großen Ursache: ein tiefer Entwurfsfehler, ein subtiles Zusammenspiel, eine schwer greifbare Bedingung. Die Suche richtet sich entsprechend aus — man sucht das Komplizierte, weil das Symptom kompliziert wirkt. Diese Erwartung führte an der eigentlichen Ursache zunächst vorbei.

Problem

Die Ursache war klein. Das Datenbankschema hatte sich geändert, aber die Abbildung im Code — die Stelle, an der das Modell die Datenbank auf Objekte übersetzt — war nicht mitgezogen worden. Datenbank und Modell sagten dasselbe über dieselbe Sache nicht mehr aus. Aus dieser winzigen Unstimmigkeit erwuchs ein Fehler, der sich weit vom eigentlichen Ort entfernt zeigte und deshalb schwer zu verorten war. Das Problem war nicht die Größe der Ursache, sondern der Abstand zwischen Ursache und Wirkung.

Ursache

Die tiefere Ursache war, dass eine Änderung an zwei Orten hätte geschehen müssen, aber nur an einem geschah. Schema und Abbildung sind zwei Darstellungen derselben Wahrheit; ändert sich die eine, muss die andere folgen. Wo diese Kopplung nicht sichtbar und nicht abgesichert ist — und in einem großen Projekt mit vielen Händen ist sie es selten von selbst —, kann die eine wandern, während die andere stehen bleibt. Die beiden liefen auseinander, und niemand bemerkte den Moment.

Entscheidung

Die Entscheidung nach dem Fund war weniger, diesen einen Fehler zu beheben — das war schnell getan —, als die Klasse solcher Fehler unwahrscheinlicher zu machen: die Übereinstimmung von Schema und Abbildung nicht dem Zufall und der Aufmerksamkeit Einzelner zu überlassen, sondern sichtbar und prüfbar zu machen.

Umsetzung

Das hieß, die Kopplung zwischen Datenbank und Modell dorthin zu holen, wo sie auffällt: Eine Abweichung zwischen Schema und Abbildung sollte früh und laut sichtbar werden, nicht spät und als rätselhaftes Symptom. Statt darauf zu vertrauen, dass jeder bei einer Schemaänderung auch die Abbildung nachzieht, wurde das Auseinanderlaufen selbst zu etwas, das das System bemerkt — nahe an der Ursache, nicht weit entfernt an der Wirkung.

Trade-offs

Diese Absicherung kostet: Sie fügt eine Prüfung hinzu, die gepflegt werden will, und macht den Moment einer Schemaänderung etwas schwerfälliger, weil nun beides zusammenpassen muss, bevor es weitergeht. Der Preis kauft, dass ein winziges Auseinanderlaufen nicht mehr zu einer langen, teamübergreifenden Fehlersuche wird. Anders würden wir bei einem sehr kleinen System entscheiden, in dem ein Einzelner Schema und Modell mühelos im Blick behält — dort ist die zusätzliche Prüfung mehr Aufwand als Schutz.

Was wir gelernt haben

Kleine Unstimmigkeiten zwischen Datenbank und Modell erzeugen unverhältnismäßig große Probleme, weil die Wirkung sich weit von der Ursache entfernt zeigt. Der Aufwand einer Fehlersuche bemisst sich nicht an der Größe der Ursache, sondern am Abstand zwischen Ursache und Symptom — und eine gewanderte Abbildung ist eine winzige Ursache mit großem Abstand. Deshalb lohnt es, gerade die stillen Kopplungen sichtbar zu machen: die Stellen, an denen zwei Darstellungen derselben Sache zusammenpassen müssen, aber unabhängig geändert werden können.

Wie das Batunet verändert hat

Seither behandeln wir die Übereinstimmung von Schema und Modell als etwas, das das System selbst wachen sollte, nicht als etwas, das jeder im Kopf behalten muss. Wir suchen bewusst nach den stillen Kopplungen — den Paaren, die zusammen geändert werden müssen — und machen ein Auseinanderlaufen früh sichtbar. Aus „jemand hätte daran denken müssen" ist „das System sagt es uns" geworden.

Weiterführend

• Guide: Zero-Downtime-Datenbankmigrationen — Schemaänderungen bewusst und abgesichert vornehmen.
• Guide: Business-Logik gehört nicht in Controller — die Übersetzung zwischen Datenbank und Domäne bewusst gestalten.
• Guide: Observability ist Architektur — warum eine Ursache nahe an ihrer Wirkung sichtbar sein sollte.
• Decision: PostgreSQL: JSONB vs. Tabellen — wie die Form der Daten die Kopplung zum Code prägt.

Grundlage ist die Batunet Engineering Method: stille Kopplungen sichtbar machen, Fehler nahe an der Ursache zeigen, nicht auf Aufmerksamkeit allein bauen.

Die Größe eines Fehlers verrät nichts über die Größe seiner Ursache. Am teuersten sind die winzigen Unstimmigkeiten, deren Wirkung sich weit von ihrem Ursprung entfernt zeigt.