Layered Architecture
Eine Schichtenarchitektur ordnet Code nach Arten von Verantwortung. Abhängigkeiten folgen einer festgelegten Richtung.
- SchichtLogische Gruppe mit einer Verantwortung.
- RichtungAufrufe laufen nur nach unten.
- Layer ≠ TierSchicht logisch, Tier physisch.
Einordnung
Warum das wichtig ist
Ohne Schichten mischen sich Formular, Ablauf, Fachregeln und Datenbankzugriff im selben Code. Schichten ordnen das logisch, Tiers dagegen physisch auf eigenen Rechnern oder Prozessen. Der Checkout hat vier Schichten, alle im selben Deployment.
Dieser Baustein erklärt Schichten und ihre Abhängigkeitsrichtung. Für fachliche Modulgrenzen siehe Modularer Monolith.
Auf einen Blick · Schichten mit Abwärtsrichtung
Wohin gehört das?
Der Checkout des modularen Shop-Monolithen nimmt eine Bestellung an, prüft Fachregeln und speichert das Ergebnis in SQL.
So liest du das Bild
- Schicht Die vier Bereiche Darstellung, Anwendung, Fachkern und Infrastruktur, etwa Web-UI und SQL-Adapter.
- Richtung Der Pfeil von Checkout-Anwendung zu Bestellregeln ist erlaubt, der von Bestellregeln zur Web-UI nicht.
- Layer ≠ Tier Alle vier Schichten liegen im selben Shop-Deployment, also in einem einzigen Tier.
- DarstellungWeb-UI
- AnwendungCheckout-Anwendung
- FachkernBestellregeln
- InfrastrukturSQL-Adapter
gehört in DarstellungEine Eingabeprüfung gehört zum Formular und gibt dem Nutzer sofort Rückmeldung.
Nutzen & Grenzen
Hilft, wenn
- Bei unterschiedlichen technischen Änderungsgründen ordnet die Schichtenarchitektur Aufgaben und erlaubte Aufrufe nachvollziehbar.
- Mehrere Eingangswege nutzen dieselben Anwendungsregeln, sobald eine gemeinsame Anwendungsschicht deren Ablauf bündelt.
- Unabhängige Fachregeltests gelingen mit einer Domänenschicht, die Transport und Speicherung aus den Regeln heraushält.
Grenzen
- Technische Schichten schneiden quer durch die Fachlichkeit: Eine fachliche Änderung wie die Abholung berührt alle Schichten. Deshalb liegen die Schichten im Shop innerhalb der Module, siehe Kohäsion und Modularer Monolith.
- Architecture Sinkhole: Viele Schichten reichen Aufrufe nur durch, ohne etwas zu entscheiden. Entferne Ebenen ohne eigene Aufgabe.
- In kleinen Systemen kostet ein starres Schichtenraster mehr, als es klärt. Ergänze Schichten erst bei wiederkehrenden Änderungsproblemen.
In der Praxis
- Ordne jede Entscheidung einer verantwortlichen Schicht zu. Halte fest, wo Transport übersetzt, der Ablauf gesteuert und eine Fachregel geprüft wird; so bleibt die Zuständigkeit im Code nachvollziehbar.
- Lege erlaubte Abhängigkeitsrichtungen fest und prüfe sie automatisiert. Innere Regeln sollten technische Darstellung nicht importieren; ein Architekturtest macht Rückkopplungen früh sichtbar.
- Verfolge Änderungen über die Schichtgrenzen und prüfe, ob jede Übergabe eine eigene Aufgabe erfüllt. Verknüpfe fachliche Grenzen bei Bedarf mit Modulgrenzen und Dependency Inversion.
Ausführliche Erklärung lesen
Schichten bündeln Aufgaben nach ihrer Rolle und legen fest, welche Ebene eine andere aufrufen darf. Typische Trennungen unterscheiden Darstellung, Anwendungsablauf, fachliche Regeln und technische Speicherung. Die Einteilung bleibt dann nützlich, wenn jede Schicht eine eigene Verantwortung trägt.
Die Abhängigkeitsrichtung legt fest, welche Schicht welche andere kennen darf. Eine Regel kann dadurch unabhängig von ihrer Oberfläche geprüft werden; Schutz vor Speichermechanismen entsteht erst, wenn der Kern keine Infrastrukturschicht aufruft. Fachliche Modulgrenzen ergänzen diese technische Ordnung und klären, wer welche Daten verbindlich ändert.
Die fachliche Zuständigkeit entsteht durch Separation of Concerns; Dependency Inversion hält die Abhängigkeit zwischen Kern und Technik kontrollierbar.
Streng geschichtet darf eine Schicht nur die direkt darunterliegende aufrufen, locker geschichtet auch tiefere. Im Bild ruft die Anwendung den SQL-Adapter auf, der Shop ist also locker geschichtet. Wie Abhängigkeiten zum Fachkern umgedreht werden, zeigen Dependency Inversion und Hexagonale Architektur. Eine Schicht ist eine logische Gruppe im Code, ein Tier ein physisch getrennter Teil im Betrieb.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Du wählst „Checkout-Anwendung ruft Bestellregeln auf“. Ist der Aufruf erlaubt, und wohin zeigt der Pfeil?
Lösung mit Begründung ansehen
Er ist erlaubt. Der Pfeil zeigt von der Anwendung zum Fachkern, also in die vorgesehene Richtung.
AnwendenAuf eine neue Lage übertragen
Neue Regel: Rabatt ab drei Tassen. In welche Schicht gehört sie, und was bleibt in der Web-UI?
Lösung mit Begründung ansehen
Die Rabattregel gehört in den Fachkern, weil sie für jeden Zugang gilt. Die Web-UI zeigt den Rabatt nur an, die Anwendung stößt die Prüfung an.
BewertenEine Alternative abwägen
Ein Team will Web-UI, Anwendung und SQL jeweils auf eigene Server legen (Tiers), um sauberer zu trennen. Wie bewertest du das?
Lösung mit Begründung ansehen
Vorteil: getrennte Skalierung und Absicherung je Teil. Nachteil: Netzwerkaufrufe, mehr Betrieb und mehr Fehlerquellen. Saubere Trennung entsteht schon durch Schichten im Code. Lege Tiers erst an, wenn ein konkreter Betriebsgrund besteht.
Vertiefen
Diese optionalen Vertiefungen ergänzen das Lernziel dieser Seite.
MVC · Model-View-Controller
MVC (Model-View-Controller) ordnet Interaktion innerhalb einer Benutzeroberfläche: Das Model hält darzustellenden Zustand und Regeln, die View zeigt ihn, und der Controller verarbeitet Eingaben und löst passende Aktionen aus. MVC ergänzt eine Schichtenarchitektur auf der UI-Seite, beschreibt aber nicht automatisch deren gesamte Abhängigkeitsrichtung oder fachliche Modulgrenzen. Die konkrete Aufteilung variiert je Framework.
Zum AusprobierenOrdne im Shop-Checkout eine Eingabe zu: Die View zeigt Warenkorb und Validierungsfehler, der Controller verarbeitet den Klick auf „Bestellen“ und ruft den Anwendungsablauf auf, das Model liefert den dafür benötigten Zustand. Prüfe, dass die View keine Bestellregel oder Datenbankschreiboperation selbst ausführt.
Weiterführende Bausteine
Quellen
- Microsoft · N-tier Architecture (öffnet in neuem Tab)Erklärt Schichten, physische Tiers und ihre unterschiedlichen Aufgaben.
- Microsoft · Common Web Application Architectures (öffnet in neuem Tab)Vergleicht Schichten und Clean Architecture einschließlich Abhängigkeitsrichtung.
- Microsoft · Architectural Principles (öffnet in neuem Tab)Erklärt Separation of Concerns, Kapselung und Dependency Inversion.
- Martin Fowler · Model View Controller (öffnet in neuem Tab)Trennung von Modell, Darstellung und Verarbeitung von Benutzereingaben.