Schichtenarchitektur

Definition und Ursprung

Eine Schichtenarchitektur gliedert eine Anwendung in horizontale Schichten, von denen jede eine technische Verantwortung hat, der Schicht darüber Dienste anbietet und die Dienste der Schicht darunter nutzt. Sie ist der am weitesten verbreitete Stil für Geschäftsanwendungen, oft eher aus Gewohnheit als aus einer Entscheidung heraus, weil die meisten Web-Frameworks ein Projekt mit Ordnern für Views, Geschäftslogik und Models erzeugen.

Die Idee ist alt und stammt aus der Systemsoftware. Edsger Dijkstra beschrieb das Multiprogramming-Betriebssystem THE (Communications of the ACM, 1968) als Hierarchie von Ebenen, von denen jede nur auf den darunterliegenden aufbaut, sodass sich jede Ebene für sich betrachten und testen ließ. Netzwerkprotokollstapel wie das OSI-Referenzmodell nutzen dasselbe Prinzip. In der Geschäftssoftware kam die Schichtenbildung mit Client-Server- und dreistufigen Systemen in den 1990er-Jahren an, und POSA (1996) katalogisierte sie als Layers-Muster. Garlan und Shaw führten Schichtensysteme unter ihren grundlegenden Stilen auf, mit der Randbedingung, dass Interaktionen auf benachbarte Schichten beschränkt sind.

Die typische Geschäftsanwendung hat vier Schichten. Die Präsentationsschicht kümmert sich um die Benutzeroberfläche und das Protokoll: HTTP-Anfragen, Bildschirmmasken, JSON. Die Geschäftsschicht enthält die Regeln und Anwendungsfälle: wie eine Bestellung bepreist wird, wann sie storniert werden darf. Die Persistenzschicht wandelt Geschäftsobjekte in gespeicherte Daten und zurück, meist über Repositories und einen objektrelationalen Mapper. Die Datenbankschicht ist die Datenbank selbst. Kleine Anwendungen legen Geschäftslogik und Persistenz manchmal zusammen; größere fügen Schichten hinzu, etwa eine Anwendungsschicht, die Anwendungsfälle über einer Domänenschicht mit dem Kernmodell koordiniert. Der Stil legt nicht die Anzahl fest, sondern die Richtung der Abhängigkeit.

Funktionsweise: geschlossene Schichten, offene Schichten und Isolation

Jede Schicht kann geschlossen oder offen sein. Eine Anfrage muss eine geschlossene Schicht durchlaufen: Die Präsentationsschicht darf nicht an der Geschäftsschicht vorbei in die Persistenzschicht greifen, auch wenn das schneller zu schreiben wäre. Eine offene Schicht darf umgangen werden. Das übliche Beispiel ist eine Schicht gemeinsamer technischer Dienste, etwa für den E-Mail-Versand, das Erzeugen von PDF-Belegen oder das Schreiben von Audit-Einträgen. Nur manche Geschäftsoperationen brauchen sie, daher würde es sinnlosen Weiterleitungscode erzeugen, jede Anfrage durch diese Schicht zu zwingen. Im Diagramm darf die Geschäftsschicht die Dienstschicht aufrufen oder direkt an ihr vorbei zur Persistenz gehen.

Geschlossene Schichten ergeben Isolationsschichten (Layers of Isolation). Weil die Präsentationsschicht nur die Schnittstelle der Geschäftsschicht kennt, kann das Team den objektrelationalen Mapper ersetzen, die Tabellen umstrukturieren oder von einem Datenbankprodukt zu einem anderen wechseln, ohne einen einzigen Controller oder ein Template anzurühren, solange die Schnittstelle der Geschäftsschicht gleich bleibt. Das ist Information Hiding (David Parnas, 1972), angewandt auf eine ganze Ebene des Codes, und es ist der Hauptnutzen, den der Stil bietet. Jede offene Schicht und jede Ausnahme, die einer Schicht erlaubt, eine andere zu überspringen, schwächt ihn: Fragen Controller die Datenbank direkt ab, greift eine Schemaänderung nun auch auf die Präsentationsschicht über.

Die Richtung der Abhängigkeit ist die andere Hälfte der Regel. Untere Schichten dürfen nichts von höheren wissen: Die Persistenzschicht darf nie einen Controller importieren, und die Geschäftsschicht darf nie HTML erzeugen. Muss eine untere Schicht eine höhere benachrichtigen, geschieht das über eine Abstraktion, die der unteren Schicht gehört, etwa eine Callback-Schnittstelle oder ein Event, sodass die Abhängigkeit im Code weiterhin nach unten zeigt. Abschnitt 3.4 behandelt Abhängigkeitsrichtung, Zyklen und strikte gegenüber gelockerter Schichtenbildung ausführlich.

Es hilft, Schichten und Tiers auseinanderzuhalten. Eine Schicht ist eine logische Gruppierung im Code. Ein Tier ist eine physische Grenze zur Laufzeit, etwa ein separater Server oder Prozess. Ein klassisches Three-Tier-System betreibt Browser, Anwendungsserver und Datenbankserver als drei Tiers, während der Anwendungsserver allein drei oder vier Schichten enthalten kann. Macht man aus einer Schicht ein Tier, liegt ein Netzwerk zwischen zwei Schichten, die einander vorher im Arbeitsspeicher aufgerufen haben, was die Kosten jedes Aufrufs vervielfacht; das lohnt sich selten um seiner selbst willen.

Beispiel: eine klassische Webanwendung

Nehmen wir die Bestellwebsite eines regionalen Essenslieferunternehmens: Kunden sehen sich Speisekarten an, geben Bestellungen auf und bezahlen; das Restaurantpersonal sieht eingehende Bestellungen. Ein Team aus fünf Personen baut sie mit einem verbreiteten Web-Framework und einer PostgreSQL-Datenbank. Eine Schichtenstruktur ist der naheliegende Ausgangspunkt, und die Codeaufteilung macht die Schichten sichtbar.

foodshop/
  presentation/          # HTTP only: parse requests, render responses
    order_views.py
    menu_views.py
    templates/
  business/              # rules and use cases; no HTTP, no SQL
    order_service.py
    pricing.py
  services/              # open layer: shared technical services
    email.py
    receipts.py
  persistence/           # all database access
    order_repository.py
    menu_repository.py
    models.py
  settings.py

Die Folgen technischer Partitionierung

Weil Schichtenbildung technische Partitionierung ist, wird die Fachdomäne über die Schichten verschmiert. Es gibt keinen einzelnen Ort namens Lieferung: Es gibt Liefer-Controller, Liefer-Services und Liefer-Repositories, vermischt mit allem anderen in jeder Schicht. Wer verstehen will, wie Trinkgeld funktioniert, muss quer durch alle lesen. Mit dem Wachstum des Systems wird jede Schicht zu einer großen Sammlung unzusammenhängenden Codes mit geringer Kohäsion: Die Geschäftsschicht enthält Regeln für Bestellungen, Zahlungen, Speisekarten und Kuriere nebeneinander, und nichts hindert den Zahlungscode daran, tief in den Speisekartencode hineinzurufen. Mit der Zeit bleiben die Schichten sauber, aber das Innere jeder Schicht wird zu einem Big Ball of Mud.

Es gibt auch organisatorische Kosten. Teams nach Schichten zu organisieren (ein Frontend-Team, ein Backend-Team, ein Datenbankteam) bedeutet, dass fast jedes Feature eine Übergabe und eine Warteschlange zwischen Teams braucht, was das Gesetz von Conway dann in der Architektur festschreibt. Martin Fowler bezeichnet nach Schichten organisierte Teams aus diesem Grund als Anti-Pattern: Die einzelnen Entwickler müssen nicht Full-Stack sein, die Teams aber schon. Eine Schichtenarchitektur zwingt Teams nicht, sich nach Schichten aufzuteilen, macht es aber zum Weg des geringsten Widerstands.

Schließlich ist ein Schichtenmonolith ein einziges Architekturquantum: eine Deployment-Einheit und meist eine Datenbank. Jede Änderung, so klein sie auch ist, bedeutet, die ganze Anwendung zu bauen, zu testen und neu zu deployen, und die ganze Anwendung skaliert und fällt als Einheit aus. Das ist oft völlig akzeptabel, setzt aber eine Obergrenze.

Das Architecture Sinkhole und andere Anti-Patterns

Das Anti-Pattern Architecture Sinkhole, ein von Mark Richards bekannt gemachter Name, beschreibt Anfragen, die durch Schichten fließen, die nichts tun, als sie weiterzureichen. Eine Speisekarte anzusehen ist der typische Fall: Der Controller ruft eine Servicemethode auf, die eine Repository-Methode aufruft, die eine Abfrage ausführt, und Controller und Service fügen nichts hinzu. Jede durchreichende Schicht bringt Code mit sich, der geschrieben, getestet und gelesen werden muss, und ein wenig Latenz. Ein gewisses Maß an Durchreichen ist der Preis der Isolation und in Ordnung. Richards bietet eine Faustregel an: Ist etwa ein Fünftel der Anfragen einfaches Durchreichen, ist das normal; sind es die meisten, besteht die Anwendung wahrscheinlich überwiegend aus Datenzugriff mit wenig Geschäftslogik, und die Schichtenbildung ist der falsche Stil oder die Schichten sollten geöffnet werden. Schichten zu öffnen gibt allerdings Isolation auf, also entscheiden Sie bewusst und halten Sie fest, warum.

Weitere häufige Anti-Patterns sollte man früh erkennen. Undichte Schichten: SQL in Controllern, HTTP-Anfrageobjekte, die an Services übergeben werden, oder ORM-Entitäten, die direkt als JSON gerendert werden, sodass eine Änderung in einer Schicht auf andere übergreift. Abhängigkeiten nach oben: ein Repository, das einen Service aufruft, oder ein Domänenobjekt, das HTML formatiert. Die anämische Geschäftsschicht: Services, die nur Daten umherschieben, während die eigentlichen Regeln in Controllern oder Stored Procedures leben; Fowler benannte 2003 das verwandte Anti-Pattern Anemic Domain Model. Der Gott-Service: ein OrderService mit mehreren tausend Zeilen, den jeder andere Service aufruft. Die Utility-Schicht, von der alles abhängt: ein common-Paket, das nach und nach Geschäftslogik ansammelt und alles mit allem koppelt.

Wann sie gut passt und wann nicht

Die Schichtenarchitektur ist eine gute Wahl für kleine und mittlere Anwendungen, die ein Team baut, für Produkte, deren Domäne noch nicht gut verstanden ist (fachliche Partitionierung braucht Grenzen, die Sie noch nicht kennen), für knappe Budgets und Fristen und für Anwendungen, die überwiegend aus Formularen über Daten mit überschaubaren Regeln bestehen. Sie ist auch eine vernünftige innere Struktur für ein einzelnes Modul oder einen Service, der selbst Teil eines fachlich partitionierten Systems ist: Ein geschichtetes delivery-Modul innerhalb eines modularen Monolithen bekommt das Beste aus beiden Welten.

Als oberste Struktur eines großen Systems mit mehreren Teams ist sie eine schlechte Wahl, weil jedes Team in jeder Schicht arbeitet und Features kollidieren. Sie ist schlecht, wenn Teile des Systems sehr unterschiedliche Skalierbarkeit oder Verfügbarkeit brauchen, weil es nur ein Quantum gibt. Und sie ist schlecht, wenn die Geschäftslogik reichhaltig und zentral ist, weil die Regeln über Controller, Services und Stored Procedures verstreut werden; dort hält eine domänenzentrierte innere Struktur wie hexagonale oder Clean Architecture den Kern unabhängig von der Datenbank und dem Web-Framework.

Der häufigste Entwicklungspfad führt von einem Schichtenmonolithen zu einem modularen Monolithen: ein Deployment behalten, aber die oberste Ebene nach Domänen neu ordnen und die Schichten innerhalb jedes Moduls beibehalten.

Die Schichtenregeln im Code durchsetzen

Schichtenregeln verfallen schnell. Unter Termindruck importiert jemand das Repository direkt in einen Controller, weil das zwanzig Minuten spart, im Review fällt es niemandem auf, und der Nächste kopiert das Muster. Die Abwehr ist ein Architekturtest: eine automatisierte Prüfung von Abhängigkeiten, die im Build läuft und ihn scheitern lässt, wenn eine Regel verletzt wird, wodurch die Regel zu einer Fitness Function wird.

In Python liest import-linter Verträge aus einer Konfigurationsdatei. Sein layers-Vertrag listet die Schichten von der höchsten zur niedrigsten auf und verbietet jeder niedrigeren Schicht, eine höhere zu importieren. Für sich allein macht er die Schichten nicht geschlossen (eine höhere Schicht darf jede niedrigere importieren), daher fügt ein forbidden-Vertrag die Regel hinzu, dass die Präsentation die Persistenz nicht direkt importieren darf; dafür muss allow_indirect_imports eingeschaltet sein, weil sonst die normale Kette von der Präsentation über die Geschäftslogik zur Persistenz als Verstoß zählen würde. In Java drückt ArchUnit dieselben Regeln als Unit-Test aus: layeredArchitecture() deklariert die Schichten nach Paketen und legt zum Beispiel fest, dass auf die Persistenzschicht nur die Serviceschicht zugreifen darf. Ähnliche Werkzeuge gibt es für andere Ökosysteme, etwa dependency-cruiser für JavaScript und TypeScript.

Zwei Praktiken sorgen dafür, dass die Prüfungen wirken. Führen Sie sie mit den vorhandenen Verstößen als bekannte Ausnahmen ein, sodass der Build sofort grün ist und nur neue Verstöße ihn scheitern lassen; bauen Sie die Ausnahmen dann nach und nach ab. Und halten Sie die Konfiguration neben dem Code und prüfen Sie Änderungen daran wie Code, denn eine Regel zu lockern ist eine Architekturentscheidung, die ein Entscheidungsdokument verdient.

[importlinter]
root_package = foodshop

[importlinter:contract:layers]
name = Layers only depend downwards
type = layers
layers =
    foodshop.presentation
    foodshop.business
    foodshop.services
    foodshop.persistence

[importlinter:contract:closed-business]
name = Presentation must go through business
type = forbidden
source_modules = foodshop.presentation
forbidden_modules = foodshop.persistence
# presentation -> business -> persistence is the normal path
allow_indirect_imports = True