Softwarearchitektur: Schichtenmodell / Layers

Dieser Beitrag ist eine Begriffserklärung zum Schichtenmodell – inklusive Prüfungsfragen und Tags.

In a Nutshell

Layered Architecture organisiert Systeme in getrennte Ebenen mit klaren Aufgaben – für saubere Trennung, Wartbarkeit und Skalierbarkeit.

Kompakte Fachbeschreibung

Das Schichtenmodell gliedert eine Anwendung in vertikal gestapelte, logisch getrennte Schichten. Jede Schicht hat eine Verantwortung und kommuniziert nur mit der direkt darunterliegenden.

Typisch:

• Präsentation (UI)
• Geschäftslogik (Controller/Services)
• Datenzugriff (DAO/Repository)
• Infrastruktur (Logging, Security, Caching)

Prüfungsrelevante Stichpunkte

• Klare Zuständigkeiten pro Schicht
• Kommunikation nur mit Nachbarschicht
• Fördert Wartbarkeit/Testbarkeit
• Häufig in IHK-Projekten
• Security: Validierung/Zugriffskontrolle in mittleren Schichten
• Doku: Schichtendiagramm + Schichtenbeschreibung

Kernkomponenten

1. UI
2. Business
3. Datenzugriff
4. Infrastruktur
5. DTOs
6. Validierung
7. Fehlerbehandlung
8. Service-Layer
9. Auth/AuthZ
10. Build/Deploy-Struktur

Praxisbeispiel

Buchungssystem:
UI (React) → Business (Java) → Datenzugriff (JPA)

Vorteile und Nachteile

Vorteile

• Gute Testbarkeit
• Teamarbeit (Frontend/Backend/DB)
• Austauschbarkeit

Nachteile

• Overhead bei kleinen Projekten
• Performanceverluste bei zu vielen Schichten

Typische Prüfungsfragen (mit Kurzantwort)

1. Ziel des Schichtenmodells? Trennung von Verantwortlichkeiten.
2. Was darf eine Schicht nicht? Direkt mit nicht-benachbarten Schichten sprechen.
3. Wo gehört Validierung hin? In die Business-Schicht.

Weiterführende Infos

1. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/layered
2. https://arc42.org/