Zum Hauptinhalt springen

Layered Architecture (Schichtenarchitektur)

Einleitung

Layered Architecture strukturiert Anwendungen in horizontale Schichten, die jeweils eine klar definierte Verantwortung tragen.

Typische Schichten:

  • Presentation
  • Application / Business
  • Data Access
  • Database

Ziel:

Komplexität durch Separation of Concerns beherrschen.


Einordnung

Layered Architecture ist ein Architekturstil für Anwendungen.

Sie definiert:

  • logische Verantwortungsbereiche
  • Abhängigkeitsrichtung zwischen Schichten

Sie ist:

  • kein Deployment-Muster
  • kein Domain-Entkopplungsstil
  • sondern ein Strukturprinzip

Grundprinzip

Regel:

Abhängigkeiten verlaufen von oben nach unten. Keine Rückkopplung.


Logische Layer vs. Physische Tiers

Logische Layer

  • Struktur innerhalb eines Deployables
  • Trennung im Code

Physische Tiers (N-Tier)

  • Schichten laufen auf separaten Servern
  • Beispiel: Webserver → Appserver → DB

Wichtig:

Layer ≠ automatisch Tier.


Charakteristika

  • Horizontale Strukturierung
  • Klare Verantwortungsbereiche
  • Oft gemeinsame Datenbank
  • Vertikale Feature-Schnitte sind nicht primär

Vorteile

  • Einfach verständlich
  • Gut dokumentierbar
  • Stabil bei planbaren Systemen
  • Gut geeignet für klassische Enterprise-Systeme

Risiken / typische Fallstricke

1️⃣ Feature-Durchstich

Eine kleine Feature-Änderung erfordert Anpassungen in:

  • UI
  • Business
  • Data Access
  • DB

→ Iterationen werden langsamer.


2️⃣ Horizontale Team-Silos

Organisation entlang von Schichten:

  • UI-Team
  • Backend-Team
  • DB-Team

→ Wartezeiten, Übergaben, Verantwortungsdiffusion.


3️⃣ Erosion durch Layer-Sprünge

In der Praxis entstehen:

  • „Shortcut“-Zugriffe
  • direkte DB-Calls aus oberen Schichten

→ Architektur bricht schleichend.


Wann sinnvoll?

  • Stabil geplante Systeme
  • Klassische Enterprise-Anwendungen
  • Legacy-Modernisierung
  • Geringe organisatorische Fragmentierung

Wann weniger sinnvoll?

  • Hohe Änderungsdynamik
  • Feature-Teams mit End-to-End-Ownership
  • Event-getriebene oder stark modulare Systeme
  • Microservices-Landschaften

Strategische Perspektive

Layered Architecture ist:

  • horizontal organisiert
  • gut kontrollierbar
  • stabil bei klarer Planung

Aber:

Sie fördert nicht automatisch:

  • Domänenentkopplung
  • Team-Autonomie
  • technologische Austauschbarkeit

Abgrenzung zu verwandten Stilen

StilFokus
LayeredHorizontale Verantwortungsstruktur
HexagonalPorts & Adapter, Symmetrie außen
CleanDependency Rule + Schichtenformalismus
Modular MonolithVertikale Module innerhalb eines Deployables

Layered Architecture ist oft der Ausgangspunkt, während Hexagonal und Clean eine stärkere Entkopplung des Kerns anstreben.


Fazit

Layered Architecture ist:

  • einfach
  • strukturiert
  • bewährt

Sie eignet sich besonders für:

stabile, planbare Systeme mit klaren Verantwortlichkeiten.

Für hochdynamische, domänengetriebene Systeme ist sie oft zu starr und horizontal geschnitten.