Schichtenarchitektur (3-Tier)

Bisher haben wir Software modelliert – aus Anforderungen entstanden Use-Cases, Aktivitäten, Sequenzen und Komponenten. Jetzt wechseln wir zur Architektur-Sicht: wie strukturiert man die Software überhaupt? Welche Bausteine gibt es, und wie ordnet man sie sinnvoll an?

Die Antwort auf die häufigste Variante dieser Frage heißt Schichtenarchitektur – das wichtigste Architektur-Muster der Software-Welt. Wer ein Web-Backend, eine Geschäftsanwendung oder eine Desktop-Software schreibt, baut mit hoher Wahrscheinlichkeit auf einer Schichtenarchitektur auf, ob er es weiß oder nicht.

1) Das Grundprinzip: jede Schicht hat eine Aufgabe

Eine Schichtenarchitektur teilt das System in mehrere übereinander liegende Schichten auf, von denen jede eine klar definierte Verantwortlichkeit hat. Die Schichten kommunizieren nur mit der direkt darunter liegenden – nicht überspringen, nicht von unten nach oben außer als Antwort. Klingt simpel, hat aber riesige Konsequenzen für die Wartbarkeit.

Eine sehr passende Analogie ist ein Restaurant: vorne steht der Kellner (Präsentationsschicht), er nimmt Bestellungen vom Gast und gibt sie an die Küche weiter. In der Küche entscheiden die Köche (Geschäftslogik), was wie zubereitet wird. Die Zutaten kommen aus der Vorratskammer (Datenzugriff). Der Gast sieht nie die Küche, der Koch geht nie zum Lieferanten – jeder bleibt in seiner Rolle. Genau diese Trennung macht das System veränderbar: ein neuer Kellner muss nicht kochen lernen, ein neuer Koch nicht die Lagerverwaltung verstehen.

2) Die klassische 3-Schichten-Architektur

Das am häufigsten verwendete Modell hat genau drei Schichten – daher der Name 3-Tier oder 3-Schicht-Architektur. Klick auf eine Schicht, um Details zu sehen:

3) Ein Request wandert durch die Schichten

Wie sieht das konkret aus, wenn ein Nutzer eine Aktion auslöst? Schauen wir uns einen typischen Webrequest an: ein Kunde klickt im Browser „Meine Bestellungen anzeigen". Klick durch die Schritte und sieh, wie der Request die Schichten durchwandert und die Antwort zurückkommt:

4) Warum überhaupt schichten? – Die Vorteile

Die Strenge der Schichten kostet auch Zeit – Code muss durch mehrere Stellen wandern, statt direkt zum Ziel zu gehen. Lohnt sich das? Praktisch immer. Hier eine Gegenüberstellung:

5) Varianten: 2-Tier, 3-Tier, N-Tier

Die Bezeichnung „Tier" kann verwirren. „Tier" und „Layer" werden oft synonym gebraucht, sind aber streng genommen unterschiedlich: Layer bezeichnet eine logische Trennung im Code, Tier eine physische Trennung auf verschiedene Maschinen. In der Praxis vermischen sich die Begriffe. Diese Modelle solltest du kennen:

6) MVC: ein Schichten-Muster innerhalb der Präsentation

Innerhalb der Präsentationsschicht hat sich ein eigenes Muster etabliert, das die UI weiter strukturiert: Model-View-Controller, kurz MVC. Es ist kein Konkurrent zur 3-Schicht-Architektur, sondern ergänzt sie auf einer feineren Ebene. MVC ist allgegenwärtig: in Spring, Rails, Laravel, React (in abgewandelter Form), iOS, Android – überall.

7) Verwandte Architektur-Patterns

Schichten- und MVC-Architektur sind nicht die einzigen Strukturierungs-Patterns. Diese verwandten Konzepte begegnen dir in der Praxis und gelegentlich in IHK-Klausuren:

8) Wie strikt müssen die Schichten sein?

In der reinen Lehre dürfen Schichten nur ihre direkten Nachbarn kennen – Frontend kommuniziert mit Backend, Backend mit DB. Das Frontend „weiß" nichts von der DB. In der Praxis gibt es zwei Auffassungen:

• Strikte Schichten: jede Schicht kennt nur die direkte Nachbarschicht darunter. Vorteil: maximale Entkopplung. Nachteil: viel „Durchreichen" – die Logik-Schicht ruft die DB-Schicht und reicht das Ergebnis weiter, auch wenn sie selbst nichts damit macht.
• Offene Schichten: Schichten dürfen auch tiefere Schichten überspringen, wenn es Sinn ergibt. Vorteil: weniger Boilerplate. Nachteil: weichere Trennung, mehr Abhängigkeiten.

In Klausuren wird meist die strikte Variante als Ideal verwendet. In der Praxis trifft man auf Mischformen – pragmatisch, aber mit der Pflicht, die Architektur-Entscheidung zu dokumentieren.

9) Konkrete Umsetzung im Code

So sieht eine typische 3-Schicht-Architektur in einem Java-Spring-Backend aus. Die Code-Struktur spiegelt direkt die Schichten wider – das hilft beim Aufrechterhalten der Trennung:

• Präsentation: controllers/ – nimmt HTTP-Requests entgegen, ruft Service-Methoden, gibt JSON zurück. Beispiel: OrderController.java.
• Geschäftslogik: services/ – Geschäftsregeln und Workflows. OrderService.calculatePrice(order) kennt z.B. die Rabatt-Logik.
• Datenzugriff: repositories/ – Datenbank-Zugriff. OrderRepository erweitert JpaRepository und liefert Methoden wie findByUserId().
• Datenmodell: entities/ oder models/ – die Datenklassen, oft mit JPA-Annotationen.

In anderen Sprachen sind die Bezeichnungen leicht anders (Python: oft views/, services/, models/), das Grundprinzip aber überall gleich.

10) Klausur-Fokus

In IHK-Klausuren werden zur Schichtenarchitektur regelmäßig folgende Punkte abgefragt:

• „Nennen und erklären Sie die drei Schichten einer 3-Tier-Architektur." – Präsentations-, Geschäftslogik-, Datenzugriffsschicht. Aufgaben und typische Technologien.
• „Welche Vorteile bietet eine Schichtenarchitektur?" – Trennung der Verantwortlichkeiten, Austauschbarkeit, Testbarkeit, Teamarbeit, Wiederverwendung.
• „Was ist MVC?" – Model-View-Controller, Trennung von Daten, Darstellung und Eingabeverarbeitung.
• „In welcher Schicht würden Sie folgendes implementieren?" – z.B. „Validierung der Eingabe" → Präsentationsschicht (Basis-Validierung) und Geschäftslogikschicht (fachliche Regeln). „Speichern in der DB" → Datenzugriffsschicht. Achtung: doppelte Validierung ist üblich – Frontend prüft schnell, Backend prüft sicher (siehe K11 Secure Coding).
• „Welche Probleme entstehen, wenn die Schichten nicht eingehalten werden?" – enge Kopplung, schwere Wartbarkeit, Test-Probleme, schlechte Wiederverwendung.

Zusammenfassung

Die Schichtenarchitektur ist das wichtigste Strukturierungs-Pattern in der Software-Entwicklung. Sie teilt das System in übereinander liegende Schichten mit klar getrennten Verantwortlichkeiten. 3-Tier-Architektur ist der Klassiker: Präsentationsschicht (UI, was der Nutzer sieht), Geschäftslogikschicht (Regeln, Berechnungen, Workflows) und Datenzugriffsschicht (Speicherung, DB-Zugriff). Wichtigste Regel: Aufrufe gehen nur von oben nach unten, jede Schicht kennt nur die direkte Nachbarschicht. Vorteile: Trennung der Verantwortlichkeiten, Austauschbarkeit (Frontend / DB können getauscht werden ohne Logik anzufassen), Testbarkeit (Schichten isoliert testbar), Teamarbeit (Frontend/Backend parallel), Wiederverwendung, Standard-Pattern. Nachteile: Overhead, Boilerplate, Performance-Kosten beim Schichtwechsel (meist vernachlässigbar). Tier-Modelle: 1-Tier (alles auf einem Rechner, Monolith), 2-Tier (Client-Server), 3-Tier (Standard heute), N-Tier (zusätzliche Schichten wie Caching, Gateway). Begriffe Layer (logisch) und Tier (physisch) sind streng genommen unterschiedlich, werden in der Praxis aber oft synonym verwendet. MVC (Model-View-Controller) ist ein eigenes Pattern innerhalb der Präsentationsschicht: Model = Daten, View = Darstellung, Controller = Eingabe-Verarbeitung. Allgegenwärtig in Spring, Rails, iOS, Android. Verwandte Architekturen: Hexagonale Architektur (Ports & Adapters), Clean Architecture (konzentrische Ringe), Pipes-and-Filters, Event-driven, Microservices (L7), Serverless. Code-Struktur: in Java/Spring typisch controllers/ services/ repositories/ entities/, in anderen Sprachen ähnlich. Klausur-Fokus: die drei Schichten benennen, Vorteile erklären, MVC kennen, einordnen welche Aufgabe in welche Schicht gehört. Schichten und Microservices sind keine Gegensätze – sie ergänzen sich oft, jeder Microservice hat selbst wieder eine Schichtenarchitektur. Die nächste Lektion vertieft genau das: Microservices vs. Monolith.