Modul 3: Architectural Styles — vom Layered zu Microservices

Architekturstile

Ein Architekturstil definiert die grobe Struktur eines Systems: Welche Bausteine gibt es, wie hängen sie zusammen, und welche Abhängigkeitsrichtung gilt. Kein Stil ist "richtig" — jeder tauscht Komplexität an einer Stelle gegen Vereinfachung an einer anderen. Die Wahl hängt von Teamgröße, Domänenkomplexität und Skalierungsanforderungen ab.

Lesson 1: Layered Architecture

Der Klassiker: Schichten übereinander (Presentation, Business, Persistence, Database), Abhängigkeiten zeigen nur nach unten. Vorteil: intuitiv und durchdacht für CRUD-Anwendungen. Nachteil: Business-Logik verwassert oft, und die Datenbank ist das Zentrum statt der Domäne. Für viele Anwendungen trotzdem der pragmatische Start.

Lesson 2: Hexagonal Architecture (Ports & Adapters)

Die Domäne sitzt im Zentrum und kennt keine Infrastruktur. Die Außenwelt erreicht sie über Ports (Interfaces) und Adapters (Implementierungen) — HTTP-Controller, DB-Repositories, Message-Listener sind alles nur Adapter. Vorteil: Die Domäne ist testbar ohne Datenbank und Webserver, und Infrastruktur ist austauschbar. Ideal, wenn die Business-Logik komplex ist.

src/main/java/com/example/cropguard/
  domain/                    # Kern — kennt keine Infrastruktur
    policy/Policy.java       # Entity + Geschäftsregeln
    policy/PolicyRepository.java  # Port (nur Interface)
  adapter/
    in/http/PolicyController.java   # Driving Adapter (REST)
    out/jpa/JpaPolicyRepository.java # Driven Adapter (DB)

Pfeilrichtung beachten: Abhängigkeiten zeigen immer von außen nach innen.

Lesson 3: Clean Architecture

Clean Architecture (Robert C. Martin) verallgemeinert Hexagonal: Konzentrische Kreise mit der Abhängigkeitsregel "alles zeigt nach innen". Entities und Use Cases im Kern, Frameworks und Treiber außen. Der Punkt ist nicht die Anzahl der Kreise, sondern die Richtung: Die Domäne definiert Interfaces, die Infrastruktur implementiert sie (DIP auf Systemebene).

Lesson 4: Event-Driven Architecture

Services kommunizieren über Ereignisse statt direkter Aufrufe: Ein Service publiziert "OrderCreated", andere reagieren (E-Mail, Lager, Statistik). Vorteil: Lose Kopplung, gute Skalierbarkeit, einfache Erweiterung. Nachteile: Eventuelle Konsistenz (kein sofortiger Zustand), schwereres Debugging, Event-Schema-Evolution. Braucht einen Broker (Kafka, RabbitMQ) und Monitoring.

Lesson 5: Microservices — und wann sie (nicht) passen

Microservices zerlegen ein System in unabhängig deploybare Services mit eigener Datenbank. Vorteile: unabhängige Teams und Deployments, skalieren pro Service. Kosten: Netzwerk-Fehlerbehandlung, verteilte Transaktionen (Saga), Betrieb (Container, Service Mesh), Datenkonsistenz. Faustregel: Erst mit dem Monolithen erfolgreich sein — Microservices lösen Organisationsprobleme (viele Teams), keine technischen.