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).
Teil 1·Erklärung
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
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).
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.
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."
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
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.
Software-Architektur: Grundlegende Organisation eines Systems — Komponenten, deren Beziehungen, und die Prinzipien, die ihre Gestaltung leiten.
Stell dir vor, du baust ein Haus:
In Software heißt das:
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:
Vorteile: Klare Trennung, leicht zu verstehen, Standard. Nachteile: Performance (jede Schicht = Overhead), kann monolithisch werden.
Idee: UI in 3 Teile aufteilen — Model (Daten), View (Darstellung), Controller (Logik).
┌──────────┐
Click│Controller│ —— update —→ Model
───→ │ │ ↓
└──────────┘ notify
↓ ↓
┌───────┐ ←————————— ┌────┐
│ View │ render │Data│
└───────┘ └────┘
Beispiel (klassisch):
User mit Daten (name, email)UserController.show() — lädt User aus DB, übergibt an ViewFrameworks mit MVC:
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) |
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:
Nachteile:
Praxis-Tipp: Microservices sind KEIN Allheilmittel. Start mit Monolith. Splitten erst, wenn das Team > 10 Entwickler und die Domäne klar ist.
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.
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.
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.
| 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 |
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.
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.
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."
6 Aufgaben zu Stilen, Trade-offs und Anwendungsbereichen.
Klausurfragen mit Lösungen (6)
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.
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.
Zuordnungen:
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
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.
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
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.
6 typische Klausurfragen.
Klausurfragen mit Lösungen (6)
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.
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.
Lösungen pro Lücke:
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
Richtige Reihenfolge:
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
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.
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