Schichtenarchitektur:
Ein klassischer Architekturstil

    • Definition:
      • Präsentation: Darstellung für den Benutzer
      • Geschäftslogik: Fachliche Regeln des Systems
      • Datenzugriff: Kommunikation mit der Datenbank.
    • Ziel:
      • Trennung von Verantwortlichkeiten.
      • Vereinfachung der Wartung und Erweiterung.
      • Erhöhung der Sicherheit durch klare Schichten.

Wie fördert die Schichtenarchitektur Qualitätsmerkmale?

Theorie: Vorteile
    • Wartbarkeit:
      • Änderungen in einer Schicht beeinflussen andere Schichten nur minimal.
      • Die klaren Trennlinien sorgen für leichtere Erweiterungen.
    • Sicherheit:
      • Schichten wie Datenzugriffslogik kapseln sensible Funktionen.
      • Reduzierung der Angriffsfläche, da direkte Zugriffe besser kontrollierbar sind.

Praxisherausforderungen bei der Schichtenarchitektur

Realität: Typische Probleme
    • Verletzung der Trennung von Verantwortlichkeiten:
      • Direkte Datenbankaufrufe aus der Präsentationsschicht.
      • Geschäftslogik verteilt sich stark über mehrere Schichten.
    • Enge Kopplung:
      • Schichten sind oft voneinander abhängig, z. B. Änderungen am Datenmodell erfordern Anpassungen in der Geschäftslogik und in der UI.
    • Der “Big Ball of Mud”:
      • Ohne Disziplin verschwimmen die Schichtengrenzen, und das System wird unstrukturiert.
    • Sicherheitsrisiken:
      • Schwache Trennung ermöglicht, dass Sicherheitsprobleme in einer Schicht andere beeinflussen.

Mit wachsender Anwendung stößt die Schichtenarchitektur an Grenzen

Für kleine und mittelgroße Systeme kann die Schichtenarchitektur ausreichend sein.
**Bei wachsenden Anwendungen entstehen jedoch Herausforderungen:**
    • Zunehmende Abhängigkeiten werden schwerer zu verwalten.
    • Änderungen brechen häufig andere Teile des Systems.
    • Technische Details (z. B. Datenbanken, Frameworks) dominieren das Systemdesign, statt den Fokus auf Geschäftslogik zu legen.

Warum ist ein Wechsel des Architekturstils sinnvoll?

**Gründe für eine Migration zu moderneren Architekturstilen**
    1. Entkopplung erhöhen:
      • Moderne Architekturstile wie Onion oder Ports & Adapter priorisieren die Geschäftslogik und isolieren externe Systeme.
    1. Flexibilität verbessern:
      • Austausch von Details (z. B. Datenbanken, APIs) wird einfacher.
    1. Wartbarkeit und Testbarkeit:
      • Die Geschäftslogik wird unabhängig von technischen Details testbar.
    1. Langfristige Skalierbarkeit:
      • Reduziert die Kosten für spätere Änderungen und Anpassungen.

Strategien für den Wechsel des Architekturstils

**Schrittweise Migration**
    1. Trennung der Geschäftslogik von technischen Details:
      • Schaffe Abstraktionen (z. B. Ports/Schnittstellen), um die Geschäftslogik vom Datenzugriff und der UI zu entkoppeln.
    1. Aufbau moderner Schichtenkonzepte:
      • Verlagerung der Geschäftslogik in eine klare Domänenschicht (z. B. bei Onion-Architektur).
    1. Refactoring mit Fokus auf Modularität:
      • Identifiziere und extrahiere stark gekoppelten Code.
    1. Testbasierte Migration:
      • Sicherstellen, dass Änderungen durch automatisierte Tests validiert werden.

Fazit

Die Schichtenarchitektur bleibt ein praktischer Einstieg, aber:
    • Mit wachsender Komplexität kann der Architekturstil seine Grenzen erreichen.
    • Eine Migration hin zu Architekturstilen wie Onion, Ports & Adapter oder Clean Architecture kann die langfristige Wartbarkeit und Flexibilität erheblich verbessern.
    • Empfehlung:
      • Beginne mit klarer Verantwortlichkeitstrennung.
      • Plane die Architektur so, dass spätere Erweiterungen und Änderungen einfacher möglich sind.