Die Kladde ist inzwischen ein ganzes System: Module je Kontext, Aggregate in Orleans-Grains, eine Vertriebspipeline mit Event Sourcing, Outbox und Inbox, ein Netz und eine Governance in Bicep. Den Code darin haben Sie seit Modul 4.3 nach einem einzigen Stil gebaut, Ports and Adapters. Sie haben ihn gebaut, weil die Lektionen es so vorgaben, und Sie haben gesehen, was er bringt. Was Sie noch nicht gesehen haben: wie dieselbe Funktion in einem anderen Stil aussähe, und was der Unterschied in Zahlen ist.

Darum geht es in Modul 4.10. Sie bauen eine kleine Funktion, die Wiedervorlage, viermal: in Schichten, in Clean Architecture, hexagonal und als Vertical Slices. Jede Fassung bekommt danach dieselbe Änderung, und jedes Mal messen Sie dasselbe. Am Ende des Moduls entscheiden Sie mit diesen Zahlen in einem ADR, nach welchem Stil die Kladde weiter gebaut wird, und ein Architekturtest hält die Entscheidung im Build.

Diese Lektion legt den Grund dafür. Sie klärt, wovor Code-Architektur überhaupt schützt, ordnet die fünf Stile den Problemen zu, gegen die sie erfunden wurden, und legt den Messbogen fest. Gebaut wird noch nichts außer dem Übungs-Repository kladde-stile und seinem Messwerkzeug.

Vier frühere Lektionen tragen diese hier. Lektion 4.1.1 hat Architektur als die Entscheidungen beschrieben, die sich schwer rückgängig machen lassen. Lektion 4.1.2 hat Änderbarkeit und Testbarkeit als Qualitätsziele neben die fünf Säulen gestellt, in Ihrer Kladde als Q6 und Q7. Lektion 4.3.3 hat das blutleere Modell gezeigt, Lektion 4.3.5 Ports and Adapters, und Lektion 4.3.6 hat die Regeln der Richtung mit einem Architekturtest aus Reflexion in den Build gebracht. Hier kommt nichts davon noch einmal; Sie brauchen es aber zum Lesen.

Wovor Code-Architektur schützt

Ein Programm, das niemand mehr ändert, braucht keine Code-Architektur. Es läuft oder es läuft nicht. Architektur im Code lohnt sich nur, weil sich Code ändert: Eine Regel wird anders, ein Feld kommt dazu, eine Datenbank wird ersetzt, ein zweiter Weg in dieselbe Funktion entsteht. Die Frage an jeden Stil ist deshalb dieselbe, und sie stammt aus Ihrem Qualitätsziel Q6:

Wenn sich eine Sache ändert, wie viele Stellen müssen mit, und wie teuer ist es, die Änderung zu prüfen?

Daraus folgen die drei Dinge, vor denen eine Code-Architektur schützen soll:

  • Vor dem Mitziehen. Eine fachliche Änderung soll an einer Stelle passieren, nicht an zehn. Jede weitere Stelle ist eine Gelegenheit, eine zu vergessen.
  • Vor teuren Tests. Wer eine Regel nur prüfen kann, indem er eine Datenbank, einen Webserver und ein Token aufbaut, prüft sie seltener. Q7 verlangt, dass die Tests ohne Netz und in einer Minute laufen.
  • Vor dem Festkleben an Technik. Datenbank, Rahmenwerk und Cloud-Dienst wechseln selten, aber wenn, dann soll der Wechsel die Fachregeln nicht berühren. Das ist die Idee hinter der Zeile in Q6: „Kladde.Core benutzt 0 Assemblys von EF Core, ASP.NET Core, SqlClient oder Azure.“

Nichts davon ist umsonst. Jede Grenze im Code ist ein Typ mehr, eine Abbildung mehr, ein Projekt mehr. Ein Stil ist gut, wenn er genau die Grenzen zieht, die Ihre Änderungen brauchen, und keine anderen. Das herauszufinden ist die Arbeit dieses Moduls.