Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Erklärung
Software-Architekturen: Schichten, MVC, Microservices
Architektur ist das, was bleibt, wenn man Code löscht. Sie bestimmt, wie deine Software in 5 Jahren aussehen wird, viel mehr als jedes einzelne Feature.
Die Idee in einem Satz
Software-Architektur: Grundlegende Organisation eines Systems, Komponenten, deren Beziehungen, und die Prinzipien, die ihre Gestaltung leiten.
Warum Architektur wichtig ist
Stell dir vor, du baust ein Haus:
- Ohne Architektur: Wände, wo gerade Platz ist. Sieht nach 1 Jahr aus wie eine Müllhalde.
- Mit Architektur: Klare Räume, Tragwerk, Erweiterungen möglich.
In Software heißt das:
- Schlechte Architektur → jeder Bug-Fix bricht 3 andere Stellen, neue Features dauern Monate.
- Gute Architektur → Features schnell hinzufügen, Tests einfach schreiben, neue Entwickler verstehen den Code in Tagen.
1. Schichten-Architektur (Layered Architecture)
Idee: System in horizontale Schichten unterteilen, jede Schicht spricht nur mit der darunter.
┌─────────────────────────────────┐
│ Präsentations-Schicht (UI) │ ← React/Vue/HTML
├─────────────────────────────────┤
│ Business-Logic-Schicht │ ← Services, Use-Cases
├─────────────────────────────────┤
│ Persistenz-Schicht (Data) │ ← Repository, DAO
├─────────────────────────────────┤
│ Datenbank / Externe Services │ ← PostgreSQL, APIs
└─────────────────────────────────┘
Regeln:
- UI ruft Business-Logic auf, nie direkt DB.
- Business-Logic ruft Persistenz auf, nie direkt UI.
- Höhere Schicht KENNT untere, aber nicht umgekehrt.
Vorteile: Klare Trennung, leicht zu verstehen, Standard. Nachteile: Performance (jede Schicht = Overhead), kann monolithisch werden.
2. MVC (Model-View-Controller)
Idee: UI in 3 Teile aufteilen, Model (Daten), View (Darstellung), Controller (Logik).
┌──────────┐
Click│Controller│ –– update –→ Model
───→ │ │ ↓
└──────────┘ notify
↓ ↓
┌───────┐ ←––––––––– ┌────┐
│ View │ render │Data│
└───────┘ └────┘
Beispiel (klassisch):
- Model:
Usermit Daten (name, email) - View: HTML-Seite, zeigt User an
- Controller:
UserController.show(), lädt User aus DB, übergibt an View
Frameworks mit MVC:
- Ruby on Rails
- ASP.NET MVC
- Spring MVC (Java)
MVC vs. MVVM vs. MVP:
| Pattern | Wann verwenden? |
|---|---|
| MVC | Klassische Web-Apps mit Server-Rendering |
| MVVM | Frontend mit Data-Binding (Vue, Angular) |
| MVP | Älteres GUI (z.B. Java Swing) |
3. Microservices
Idee: Statt EINER großen Anwendung (Monolith) viele kleine Services bauen, jeder mit eigener DB, eigenem Team, eigenem Release-Zyklus.
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Order │ │ Payment │ │ Email │
│ Service │ │ Service │ │ Service │
│ + DB │ │ + DB │ │ + DB │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└────────────┼────────────┘
│
┌──────────┐
│ Message- │
│ Broker │
└──────────┘
Vorteile:
- Skalierbar pro Service (z.B. 10x Order-Service, 1x Email-Service)
- Tech-Stack pro Service wählbar (Java + Python + Go im selben System)
- Teams unabhängig
- Fehler-Isolation (Email-Service down ≠ Order-Service down)
Nachteile:
- Komplexität explodiert: Service Discovery, API-Gateways, verteilte Transaktionen.
- Operations-Aufwand (Container, Orchestration mit Kubernetes).
- Netzwerk-Latenz zwischen Services.
- Daten-Inkonsistenz (eventual consistency).
Praxis-Tipp: Microservices sind KEIN Allheilmittel. Start mit Monolith. Splitten erst, wenn das Team > 10 Entwickler und die Domäne klar ist.
4. Weitere wichtige Architektur-Stile
Hexagonal-Architektur (Ports & Adapters)
Idee: Business-Logik im Kern, alles außen (DB, UI, Mail) als austauschbare Adapter.
┌──────────────────────┐
│ Business-Logic │
UI ──→─ Port ────────── Port ──→ DB
│ (Hexagon) │
└──────────────────────┘
Vorteil: Business-Logik komplett isoliert, austauschbare Infrastruktur.
Event-Driven Architecture (EDA)
Idee: Services kommunizieren über Events, nicht über direkte API-Calls.
OrderService → publishes "OrderPlaced" event
↓
┌──────────┬─────────┴────────┐
PaymentService EmailService AnalyticsService
Vorteil: Lose Kopplung. Neuer Service kann ohne Anpassung der Producer abonnieren.
Serverless
Idee: Code läuft NUR bei Aufruf (Lambda, Cloud Functions). Kein Server-Management.
Pro: kein Idle-Cost, automatisch skalierbar. Contra: Cold Starts, Vendor-Lock-in, Schwer zu lokal testen.
Architektur-Trade-offs
| Aspekt | Monolith | Microservices |
|---|---|---|
| Komplexität | niedrig | sehr hoch |
| Skalierbarkeit | begrenzt | sehr gut |
| Deployment | einfach | komplex |
| Tech-Stack | einheitlich | gemischt |
| Daten-Konsistenz | einfach | schwer (CAP-Theorem) |
| Team-Größe | bis ~10 Entwickler | 50+ Entwickler |
Klausur-Faustregeln
1. Schichten-Architektur: UI → Business → Persistenz. Top-Down-Abhängigkeit, nicht umgekehrt.
2. MVC: Model (Daten), View (UI), Controller (Logik). Klassisch in Web-Apps.
3. Microservices: Viele kleine Services mit eigener DB. Hohe Komplexität, hohe Skalierbarkeit.
4. Monolith ist NICHT veraltet. Für kleine/mittlere Teams oft die beste Wahl.
5. Hexagonal-Architektur: Business-Logik im Zentrum, Infrastruktur als Adapter.
6. CAP-Theorem: Verteilte Systeme können nur 2 von 3 garantieren: Consistency, Availability, Partition-Tolerance.
Häufige Stolpersteine
1. Microservices als Default sehen. Falsch. Microservices haben enormen Overhead. Für die meisten Projekte ist ein gut strukturierter Monolith besser. Twitter, Stack Overflow waren lange Monolithen.
2. MVC und Schichten-Architektur verwechseln. MVC ist ein UI-Pattern. Schichten-Architektur ist eine System-weite Architektur. Beide können gleichzeitig verwendet werden (z.B. Spring MVC innerhalb einer Schichten-Architektur).
3. Architektur-Wahl ist permanent. Falsch, aber Wechsel ist sehr teuer. Microservices → Monolith zurück ist häufig (Segment, Khan Academy haben das gemacht).
4. Abhängigkeiten verletzen. In Schichten-Architektur ruft die Persistenz NIE die UI auf. Solche "Up-Calls" zerstören die Architektur.
5. Premature Optimization. "Wir brauchen Kubernetes für unseren MVP", meistens nein. YAGNI (You Ain't Gonna Need It) gilt auch für Architektur.
Interaktiv verstehen
Architektur-Stile im Vergleich
Wähle einen Architektur-Stil und sieh, wie die Komponenten verknüpft sind, was die Vorteile/Nachteile sind und in welchen Projekten der Stil typisch ist.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Tipp: Wenn du in der Klausur einen Architektur-Vorschlag machen sollst, IMMER mit Trade-offs argumentieren. Beispiel: "Microservices, weil das Team 50+ Entwickler hat, aber bewusst: höhere Operations-Komplexität in Kauf genommen wegen unabhängiger Deployments."
Praxis-Übung
Software-Architekturen, Praxis-Übung
6 Aufgaben zu Stilen, Trade-offs und Anwendungsbereichen.
Klausurfragen mit Lösungen (6)
- F1.Was ist die typische Schichten-Reihenfolge in einer Web-App (von oben nach unten)?
Antwort: UI → Business-Logic → Persistenz → DB
Erklärung: Standard-Schichten von oben nach unten: 1) Präsentation/UI (React, HTML), 2) Business-Logic (Services, Use-Cases), 3) Persistenz (Repository, DAO), 4) DB/Externe Services. Wichtige Regel: höhere Schicht ruft untere auf, NIE umgekehrt.
- F2.In MVC: Was ist die Aufgabe des Controllers?
Antwort: Benutzer-Aktionen entgegennehmen, Model + View koordinieren
Erklärung: Der Controller ist die Vermittlungs-Schicht: er empfängt User-Aktionen (Click, Form-Submit), ändert das Model (z.B. neuer User in DB) und sagt der View, sich zu aktualisieren. Model = reine Daten, View = reine Darstellung, Controller = Logik dazwischen.
- F3.Ordne die Architektur-Stile ihrem typischen Anwendungsbereich zu.
Zuordnungen:
- Monolith (Schichten) → Kleine bis mittlere Teams, einfache Domänen
- Microservices → 50+ Entwickler, komplexe Domäne, hohe Skalierbarkeit
- MVC → Klassische Web-Apps mit Server-Rendering
- Hexagonal → Komplexe Business-Logik, viele austauschbare Adapter
Erklärung: Jeder Stil hat sein Sweet Spot: Monolith für Standard-Projekte, Microservices NUR bei sehr großen Teams + Skalierbarkeits-Bedarf, MVC für klassische Webseiten, Hexagonal für komplexe Domänen-getriebene Software (DDD). Achtung: kein Stil ist überall der beste.
Typ: Zuordnung
- F4.Welche AUSSAGE über Microservices ist FALSCH?
Antwort: Microservices reduzieren die Komplexität gegenüber Monolithen
Erklärung: Microservices REDUZIEREN die Komplexität NICHT, sie erhöhen sie SIGNIFIKANT auf System-Ebene (Service Discovery, verteilte Transaktionen, Operations-Aufwand). Was Microservices reduzieren: Komplexität PRO SERVICE. Aber die Gesamt-System-Komplexität wächst stark. Daher: Microservices nur wenn der Skalierungs-Nutzen den Komplexitäts-Aufwand übersteigt.
- F5.In einer Schichten-Architektur darf die Persistenz-Schicht die UI-Schicht aufrufen.
Antwort: Falsch
Erklärung: FALSCH. Die Abhängigkeiten gehen IMMER nach unten: höhere Schicht ruft untere. Persistenz steht UNTER UI. Wenn Persistenz die UI aufrufen würde, wäre das ein 'Up-Call' und zerstört die Schichten-Idee. Wenn man so etwas braucht (z.B. UI über DB-Updates benachrichtigen), nutzt man Observer/Event-Patterns, NICHT direkte Aufrufe von unten nach oben.
Typ: Wahr/Falsch
- F6.Du baust einen MVP für eine kleine Startup-Idee (3 Entwickler, 1 Anwendungsfall). Welche Architektur wählst du?
Antwort: Schichten-Monolith, weil einfach und schnell zu entwickeln
Erklärung: Schichten-Monolith ist die richtige Wahl für ein MVP: schnell zu bauen, einfaches Deployment, klare Struktur, alle 3 Entwickler im gleichen Code. Microservices wären massiver Overhead für 3 Personen. YAGNI, du brauchst die Skalierbarkeit (noch) nicht. Praxis: Twitter, Shopify, Khan Academy starteten alle als Monolithen. Microservices kommen später, wenn das Team wächst.
Klausur-Quiz
Software-Architekturen, Klausur-Quiz
6 typische Klausurfragen.
Klausurfragen mit Lösungen (6)
- F1.Welcher Architektur-Stil ist das GEGENTEIL von Microservices?
Antwort: Monolith
Erklärung: Monolith (eine einzige große Anwendung) ist das klassische Gegenstück zu Microservices (viele kleine Services). Schichten und MVC sind keine Gegenteile von Microservices, sie können sogar innerhalb eines Monolithen ODER innerhalb eines Microservices verwendet werden.
- F2.In MVC: Wer rendert die HTML-Seite, die der Benutzer sieht?
Antwort: View
Erklärung: Die VIEW rendert die UI (HTML, JSON, etc.). Das Model hält die Daten. Der Controller koordiniert: er nimmt die User-Action entgegen, ändert das Model und entscheidet, welche View gerendert wird. Klassisch: Controller ruft `render('user-detail', user)` auf, Template-Engine erzeugt HTML aus User-Daten.
- F3.Microservices haben jeweils eine {{1}} Datenbank. Das CAP-Theorem besagt, dass verteilte Systeme nur 2 von 3 Eigenschaften garantieren können: {{2}}, Availability und Partition-Tolerance.
Lösungen pro Lücke:
- {{1}}: eigene / eigenständige / separate
- {{2}}: Consistency
Erklärung: Microservices teilen sich KEINE Datenbank, jeder Service hat seine eigene DB. Das ist eine harte Regel: Direktzugriff von Service A auf DB von Service B ist Anti-Pattern. CAP-Theorem (Brewer 2000): bei Netzwerk-Partition muss man wählen zwischen Consistency (alle Knoten sehen das gleiche) und Availability (alle Anfragen bekommen Antwort). Klausur-Klassiker.
Typ: Lückentext
- F4.Ordne die Schichten einer klassischen Web-App-Architektur von oben (UI) nach unten (DB).
Richtige Reihenfolge:
- Präsentations-Schicht (UI)
- Business-Logic-Schicht (Services)
- Persistenz-Schicht (Repository/DAO)
- Datenbank
Erklärung: Reihenfolge: 1) Präsentation (UI), 2) Business-Logic, 3) Persistenz, 4) DB. Aufrufrichtung IMMER nach unten. UI ruft Business-Logic auf, NIE direkt DB. Business-Logic ruft Persistenz auf, NIE direkt DB-SQL. Persistenz spricht mit DB. Das ist die klassische 4-Schichten-Architektur (oder 3-Schichten, wenn DB nicht als eigene Schicht zählt).
Typ: Reihenfolge
- F5.Was ist KEIN Vorteil der Microservices-Architektur?
Antwort: Daten-Konsistenz ist einfach zu erreichen
Erklärung: Daten-Konsistenz ist ein NACHTEIL von Microservices, KEIN Vorteil. Jeder Service hat eigene DB → keine ACID-Transaktionen über Services hinweg → 'eventual consistency' statt sofortiger Konsistenz. Das macht das System komplexer und fehleranfälliger. Wenn du strenge Konsistenz brauchst, ist ein Monolith oft besser.
- F6.Die Hexagonal-Architektur (Ports & Adapters) zielt darauf ab, die Business-Logik vollständig von der Infrastruktur (DB, UI, externe Services) zu trennen.
Antwort: Wahr
Erklärung: RICHTIG. Hexagonal-Architektur (Cockburn 2005): Business-Logik im Zentrum (das Hexagon), umgeben von 'Ports' (Interfaces) und 'Adapters' (konkrete Implementierungen). Vorteil: Business-Logik kennt KEINE Frameworks, KEINE DB-Treiber, KEINE HTTP-Libraries. Man kann DB von Postgres zu MongoDB tauschen, ohne die Business-Logik anzufassen. Sehr nützlich für Testbarkeit (Adapter mocken) und Domain-Driven Design.
Typ: Wahr/Falsch
