Softwarearchitektur: Schichtenmodell / Layers

Dieser Beitrag ist eine Begriffserklärung zum Schichtenmodell – inklusive Prüfungsfragen, Kernkomponenten und praktischen Beispielen.

Wenn Du eine Anwendung entwickelst, die über lange Zeit wartbar und erweiterbar bleiben soll, brauchst Du eine klare Struktur. Das Schichtenmodell, auch Layered Architecture genannt, ist eines der am häufigsten verwendeten Architekturmuster. Es teilt eine Anwendung in übereinander liegende Schichten auf, die jeweils eine spezifische Aufgabe erfüllen. In Prüfungen und im Berufsalltag wirst Du oft nach den Schichten, deren Aufgaben und den Regeln der Kommunikation gefragt.

In a Nutshell

Layered Architecture organisiert Systeme in getrennte Ebenen mit klaren Aufgaben. Jede Schicht kümmert sich um einen bestimmten Aspekt der Anwendung und kommuniziert nur mit der direkt darunterliegenden Schicht. Das fördert Trennung von Zuständigkeiten, Wartbarkeit, Testbarkeit und Skalierbarkeit.

Kompakte Fachbeschreibung

Das Schichtenmodell gliedert eine Anwendung in vertikal gestapelte, logisch getrennte Schichten. Jede Schicht hat eine klar definierte Verantwortung und kommuniziert in der Regel nur mit der direkt darunterliegenden Schicht. Das verhindert, dass Geschäftslogik, Darstellung und Datenspeicherung durcheinanderfließen.

Typische Schichten sind:

Präsentationsschicht (UI): Zeigt Daten an und nimmt Benutzereingaben entgegen. Sie enthält keine Geschäftslogik.
Geschäftslogikschicht (Business Layer): Enthält die Domänenlogik, Regeln und Prozesse. Hier findet die Validierung statt.
Datenzugriffsschicht (Data Access Layer): Kümmert sich um das Lesen und Schreiben von Daten, oft über Repositories oder DAOs.
Infrastrukturschicht: Stellt querschnittliche Funktionen wie Logging, Security, Caching oder Konfiguration bereit.

In vielen Varianten gibt es zusätzlich einen Service‑Layer, der als Fassade zwischen UI und Geschäftslogik dient, oder einen Domain‑Layer, der die Kernlogik besonders stark schützt.

Prüfungsrelevante Stichpunkte

Klare Zuständigkeiten pro Schicht: Jede Schicht hat eine definierte Aufgabe und enthält nur Code, der dazu gehört.
Kommunikation nur mit der Nachbarschicht: Eine Schicht sollte nicht Schichten überspringen, sondern nur direkt mit der darunterliegenden Schicht sprechen.
Trennung von Zuständigkeiten: UI, Logik und Datenzugriff sind getrennt. Das erhöht die Wartbarkeit.
Fördert Testbarkeit: Jede Schicht kann isoliert getestet werden, wenn sie über Interfaces angebunden ist.
Austauschbarkeit: Schichten können ausgetauscht werden, ohne die anderen Schichten zu verändern, wenn die Schnittstellen stabil bleiben.
Häufig in IHK‑Projekten: Das Schichtenmodell ist ein klassisches Thema in der Prüfung und wird oft in der Projektdokumentation verlangt.
Security: Validierung, Authentifizierung und Autorisierung gehören in die mittleren Schichten, nicht in die UI.
DTOs: Data Transfer Objects transportieren Daten zwischen Schichten, ohne interne Entitäten preiszugeben.
Fehlerbehandlung: Fehler werden in der Schicht behandelt, in der sie am besten aufgelöst werden können, oder an die darüberliegende Schicht weitergegeben.
Dokumentation: Ein Schichtendiagramm mit Beschreibung jeder Schicht ist in der Projektdokumentation wichtig.
Wirtschaftlichkeit: Klare Schichten reduzieren Wartungskosten und erleichtern die Einarbeitung neuer Teammitglieder.

Kernkomponenten

UI (Präsentationsschicht) Die UI‑Schicht ist die Schnittstelle zum Benutzer. Sie zeigt Daten an, nimmt Eingaben entgegen und leitet sie an die darunterliegende Schicht weiter. Sie enthält keine Geschäftslogik, sondern nur Darstellungs- und Navigationlogik.
Business (Geschäftslogikschicht) Die Business‑Schicht enthält die Kernlogik der Anwendung. Hier werden Geschäftsregeln, Berechnungen und Entscheidungen umgesetzt. Validierung findet typischerweise hier statt, bevor Daten an die Datenzugriffsschicht weitergegeben werden.
Datenzugriff (Data Access Layer) Die Datenzugriffsschicht kümmert sich um das Lesen und Schreiben von Daten. Sie abstrahiert die Datenbank oder andere Datenquellen, zum Beispiel durch Repositories oder DAOs. Die darüberliegende Schicht kennt keine Details der Datenbanktechnologie.
Infrastruktur Infrastruktur‑Komponenten sind querschnittlich: Logging, Konfiguration, Caching, Verschlüsselung, Messaging und technische Hilfsmittel. Sie können in allen Schichten genutzt werden, ohne die Geschäftslogik zu vermischen.
DTOs (Data Transfer Objects) DTOs sind einfache Objekte, die Daten zwischen Schichten transportieren. Sie enthalten keine Logik und verhindern, dass interne Entitäten oder Datenbankmodelle an die UI durchgereicht werden.
Validierung Validierung prüft, ob Eingaben den Geschäftsregeln entsprechen. Sie findet meist in der Business‑Schicht statt, teilweise ergänzt durch grundlegende Formatprüfungen in der UI‑Schicht.
Fehlerbehandlung Jede Schicht behandelt Fehler, die in ihrer Verantwortung liegen. Technische Fehler werden oft in der Datenzugriffs‑ oder Infrastrukturschicht behandelt, fachliche Fehler in der Business‑Schicht. Benutzerfreundliche Meldungen entstehen in der UI‑Schicht.
Service‑Layer Der Service‑Layer bietet eine Fassade für die Geschäftslogik. Er orchestriert mehrere Domain‑Objekte und stellt der UI‑Schicht eine klar definierte Schnittstelle zur Verfügung.
Auth/AuthZ Authentifizierung und Autorisierung gehören in die mittleren Schichten. Die UI zeigt nur an, was der Benutzer darf, aber die Entscheidung, ob ein Vorgang erlaubt ist, wird in der Business‑ oder Service‑Schicht getroffen.
Build/Deploy‑Struktur Schichten können sich in der physischen Struktur des Projekts widerspiegeln. Klare Projekte oder Pakete pro Schicht erleichtern das Verständnis und die Einhaltung der Architekturregeln.

Praxisbeispiel: Buchungssystem

Das folgende Beispiel zeigt, wie ein einfaches Buchungssystem im Schichtenmodell aufgebaut werden kann.

Was wird hier gezeigt?

Die UI‑Schicht nimmt eine Buchung vom Benutzer entgegen und zeigt Ergebnisse an.
Die Business‑Schicht prüft, ob die Buchung gültig ist, ob genügend Plätze vorhanden sind und berechnet den Preis.
Die Datenzugriffsschicht speichert die Buchung in der Datenbank und liest verfügbare Plätze aus.
Die Infrastrukturschicht protokolliert den Vorgang und stellt sicher, dass nur autorisierte Benutzer buchen können.

Warum wird das gezeigt?

Das Beispiel verdeutlicht, wie Daten und Verantwortlichkeiten durch die Schichten fließen. Es zeigt, warum die UI keine Datenbank direkt aufrufen sollte und warum die Validierung in der Business‑Schicht stattfindet. Es zeigt auch, wie DTOs verwendet werden können, um zwischen den Schichten nur die nötigen Daten zu transportieren.

Buchungssystem:

┌─────────────────────────────────────┐
│ UI‑Schicht (React)                 │
│ → Eingabe: Buchung anlegen         │
└──────────────┬──────────────────────┘
               │ DTO (BuchungRequest)
               ▼
┌─────────────────────────────────────┐
│ Service‑Schicht (Java Spring)        │
│ → Koordination, Auth‑Check           │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│ Business‑Schicht (Java)             │
│ → Validierung, Preisberechnung       │
└──────────────┬──────────────────────┘
               │ DTO (BuchungEntity)
               ▼
┌─────────────────────────────────────┐
│ Datenzugriffsschicht (JPA/Repository)│
│ → Speichern und Lesen der Buchung    │
└─────────────────────────────────────┘

Vorteile und Nachteile

Vorteile

Gute Testbarkeit: Jede Schicht kann isoliert getestet werden, wenn sie über stabile Schnittstellen verfügt.
Klare Trennung von Zuständigkeiten: UI, Logik, Daten und Infrastruktur sind getrennt. Das macht den Code übersichtlicher.
Bessere Teamarbeit: Unterschiedliche Teams können parallel an verschiedenen Schichten arbeiten, zum Beispiel Frontend, Backend und Datenbank.
Austauschbarkeit: Eine Schicht kann ausgetauscht werden, ohne die anderen zu verändern, solange die Schnittstellen gleich bleiben.
Wiederverwendbarkeit: Die Business‑Schicht kann für verschiedene UI‑Technologien oder Clients genutzt werden.
Wartbarkeit: Änderungen beschränken sich meist auf eine Schicht, was die Einarbeitung und Fehlerbehebung erleichtert.

Nachteile

Overhead bei kleinen Projekten: Für einfache Anwendungen kann das Schichtenmodell zu viel Struktur und Boilerplate‑Code erfordern.
Performanceverluste: Jede zusätzliche Schicht kann Latenz und Mapping‑Aufwand bedeuten, besonders wenn viele DTOs konvertiert werden.
Starrheit: Bei zu strikter Anwendung kann es schwierig werden, querschnittliche Funktionen sauber umzusetzen.
Komplexität: Schichtenregeln müssen eingehalten und kontrolliert werden, sonst entsteht schnell ein Mischmasch.
Falsche Verteilung: Wenn Logik in die falsche Schicht wandert, verliert das Modell seine Vorteile.

Freie Antwort

In IHK‑Projekten solltest Du das Schichtenmodell wählen, wenn Du eine Anwendung mit klar getrennten Verantwortlichkeiten dokumentieren musst. Zeige ein Schichtendiagramm, beschreibe jede Schicht in einem Satz und begründe, warum die Trennung sinnvoll ist. Erwähne, wo Validierung, Authentifizierung und Fehlerbehandlung stattfinden. Für sehr kleine Tools oder Prototypen kann das Schichtenmodell zu viel Overhead bedeuten.

Lernstrategie

1. Schichtenmodell skizzieren

Zeichne ein Schichtendiagramm mit UI, Service, Business, Datenzugriff und Infrastruktur. Markiere die erlaubte Kommunikation und notiere, welche Aufgabe jede Schicht hat.

2. Eigenes Beispiel entwickeln

Nimm ein Beispiel aus Deinem Alltag, wie ein Online‑Shop oder ein Buchungssystem. Überlege, welche Klassen in welche Schicht gehören und welche DTOs dazwischen transportiert werden.

3. Regeln üben

Formuliere die wichtigsten Regeln des Schichtenmodells in eigenen Worten: „Eine Schicht spricht nur mit ihrer direkten Nachbarschicht.“ „Die UI enthält keine Geschäftslogik.“ „Validierung gehört in die Business‑Schicht.“

4. Fehlerbeispiele analysieren

Suche Dir Code‑Beispiele, in denen Schichten vermischt werden, zum Beispiel SQL‑Abfragen direkt in der UI. Überlege, wie man den Code ins Schichtenmodell überführen könnte.

5. Prüfungsszenario durchspielen

Stelle Dir eine Prüfungsfrage vor: „Begründen Sie die Wahl des Schichtenmodells für ein Buchungssystem.“ Formuliere eine Antwort, die auf Trennung von Zuständigkeiten, Testbarkeit und Wartbarkeit eingeht.

Themenanalyse

Technischer Kern: Schichten, DTOs, Schnittstellen, Validierung, Fehlerbehandlung, Service‑Layer
Herausforderungen: Vermeidung von Schichtenvermischung, richtige Balance zwischen Strenge und Flexibilität, Overhead in kleinen Projekten
Sicherheit: Authentifizierung, Autorisierung und Validierung in den mittleren Schichten
Dokumentation: Schichtendiagramm, Beschreibung der Schichten, Begründung der Architekturwahl
Wirtschaftlichkeit: Wartbarkeit, parallele Entwicklung, Austauschbarkeit, reduzierte Kosten bei Änderungen

FAQ: Schichtenmodell und Layered Architecture

1. Was ist ein Schichtenmodell?

Ein Schichtenmodell teilt eine Anwendung in übereinander liegende, logisch getrennte Schichten auf. Jede Schicht hat eine eigene Verantwortung und kommuniziert in der Regel nur mit der direkt darunterliegenden Schicht.

2. Was ist Layered Architecture?

Layered Architecture ist ein Architekturmuster, das eine Anwendung in horizontale Schichten teilt. Es ist eines der am häufigsten verwendeten Muster in der Softwareentwicklung.

3. Welche Schichten gibt es typischerweise?

Typische Schichten sind Präsentation, Geschäftslogik, Datenzugriff und Infrastruktur. Je nach Variante gibt es auch einen Service‑Layer oder einen Domain‑Layer.

4. Was ist die Aufgabe der Präsentationsschicht?

Die Präsentationsschicht zeigt Daten an und nimmt Benutzereingaben entgegen. Sie enthält keine Geschäftslogik, sondern nur Darstellungs- und Navigationslogik.

5. Was ist die Aufgabe der Geschäftslogikschicht?

Die Geschäftslogikschicht enthält die Domänenlogik, Geschäftsregeln, Berechnungen und Validierungen. Sie ist das Herzstück der Anwendung.

6. Was ist die Aufgabe der Datenzugriffsschicht?

Die Datenzugriffsschicht kümmert sich um das Lesen und Schreiben von Daten. Sie abstrahiert die Datenbank oder andere Datenquellen, zum Beispiel durch Repositories oder DAOs.

7. Was ist die Aufgabe der Infrastrukturschicht?

Die Infrastrukturschicht stellt querschnittliche Funktionen bereit, wie Logging, Caching, Konfiguration, Verschlüsselung und Messaging.

8. Was ist ein Service‑Layer?

Ein Service‑Layer ist eine zusätzliche Schicht zwischen UI und Geschäftslogik. Er orchestriert mehrere Geschäftsprozesse und stellt der UI eine klar definierte Schnittstelle bereit.

9. Was ist ein DTO?

Ein DTO, Data Transfer Object, ist ein einfaches Objekt, das Daten zwischen Schichten transportiert. Es enthält keine Logik und verhindert, dass interne Entitäten an die UI durchgereicht werden.

10. Was bedeutet Trennung von Zuständigkeiten?

Trennung von Zuständigkeiten bedeutet, dass verschiedene Aspekte einer Anwendung, wie Darstellung, Logik und Datenzugriff, in separate Komponenten aufgeteilt werden. Das reduziert Kopplung und Komplexität.

11. Mit welcher Schicht darf eine Schicht kommunizieren?

Im klassischen Schichtenmodell kommuniziert eine Schicht nur mit ihrer direkt darunterliegenden Nachbarschicht. Das verhindert, dass Abhängigkeiten quer durch das System entstehen.

12. Was passiert, wenn Schichten vermischt werden?

Wenn Schichten vermischt werden, entsteht schnell sogenannter Spaghetti‑Code. Die Anwendung wird schwerer zu testen, zu warten und auszutauschen.

13. Wo gehört die Validierung hin?

Die fachliche Validierung gehört in die Geschäftslogikschicht. Die UI‑Schicht kann ergänzend grundlegende Formatprüfungen vornehmen, darf aber keine Geschäftsregeln entscheiden.

14. Wo gehört die Authentifizierung hin?

Authentifizierung und Autorisierung gehören in die mittleren Schichten, also Service‑ oder Business‑Schicht. Die UI zeigt nur an, was ein Benutzer sieht, aber die Entscheidung über Berechtigungen wird zentral getroffen.

15. Was ist ein Repository?

Ein Repository ist ein Muster aus der Datenzugriffsschicht. Es kapselt den Zugriff auf die Datenquelle und bietet der Geschäftslogikschicht eine saubere Schnittstelle zum Lesen und Schreiben von Daten.

16. Was ist ein DAO?

Ein DAO, Data Access Object, ist ein Objekt, das den Zugriff auf eine Datenbank oder eine andere Datenquelle kapselt. Es ist ein ähnliches Muster wie das Repository.

17. Warum ist das Schichtenmodell testbar?

Jede Schicht kann isoliert getestet werden, wenn sie über stabile Schnittstellen angebunden ist. Die Datenzugriffsschicht kann durch ein Fake oder Mock ersetzt werden, um die Geschäftslogik zu testen.

18. Warum ist das Schichtenmodell wartbar?

Änderungen beschränken sich meist auf eine Schicht. Wer die UI austauscht, muss die Geschäftslogik nicht anpassen. Wer die Datenbank wechselt, bleibt innerhalb der Datenzugriffsschicht.

19. Wann ist das Schichtenmodell nicht sinnvoll?

Bei sehr kleinen Projekten, einfachen Skripten oder Prototypen kann das Schichtenmodell zu viel Overhead und unnötigen Code erzeugen.

20. Was ist ein Schichtendiagramm?

Ein Schichtendiagramm zeigt die Schichten einer Anwendung als übereinander liegende Blöcke und die erlaubten Kommunikationswege zwischen ihnen. Es ist ein wichtiges Dokumentationsmittel.

21. Was ist der Unterschied zwischen Schichten und Tiers?

Schichten beschreiben die logische Trennung innerhalb einer Anwendung. Tiers beschreiben die physische Verteilung auf verschiedene Maschinen oder Netzwerke, zum Beispiel Client, Server und Datenbank.

22. Was ist ein Domain‑Layer?

Ein Domain‑Layer ist eine zusätzliche Schicht, die die reine Geschäftslogik besonders stark schützt. Er enthält Entitäten, Wertobjekte und Domain‑Services, unabhängig von Technologie und UI.

23. Was ist ein Hexagonales Schichtenmodell?

Das Hexagonale Modell, auch Ports and Adapters genannt, ist eine Variante des Schichtenmodells. Es trennt die Anwendungslogik im Inneren von externen Adaptern wie UI, Datenbank oder Messaging.

24. Was ist ein Onion Model?

Das Onion Model ist eine weitere Variante des Schichtenmodells. Die Domain‑Logik liegt im Zentrum, und alle anderen Schichten wie Infrastruktur und UI sind äußere Ringe, die darauf aufbauen.

25. Was sollte in der Projektdokumentation zum Schichtenmodell stehen?

Die Dokumentation sollte ein Schichtendiagramm, die Aufgabe jeder Schicht, die erlaubten Kommunikationswege und eine Begründung für die Wahl des Modells enthalten. Zusätzlich gehören Sicherheitsaspekte wie Validierung und Autorisierung dazu.