Rückblick: Was wir in Teil 1 gelernt haben

In Teil 1 haben wir erkundet:

• Warum Architektur wichtig ist — die Brücke zwischen agiler Entwicklung und nachhaltigen Systemen
• Das 4+1 Sichtenmodell — Logisch, Prozess, Entwicklung, Physisch und Szenarien
• Nichtfunktionale Anforderungen formen architektonische Entscheidungen

Heute: Vom Verstehen zum Anwenden von Architektur mit bewährten Mustern.

Das Versprechen der Muster

Wenn ein Entwickler sagt "wir verwenden MVC", verstehen andere Entwickler sofort:

• Wie Verantwortlichkeiten aufgeteilt sind
• Wo Geschäftslogik vs. UI-Code zu finden ist
• Wie neue Features hinzugefügt werden können, ohne bestehende zu zerstören

Muster sind nicht nur Code-Strukturen — sie sind gemeinsames Vokabular, das effiziente Kommunikation ermöglicht.

Lernziele

Am Ende dieser Vorlesung werden Sie in der Lage sein:

1. Architekturmuster zu erklären und warum sie als bewährte Lösungen Mehrwert bieten

2. MVC und Schichtenarchitektur anzuwenden, um interaktive Anwendungen zu strukturieren

3. Zu bewerten, wann verteilte Muster eingesetzt werden wie Client-Server und Microservices

4. Eine weiterentwickelte Architektur zu entwerfen für den Road Profile Viewer

Was ist ein Architekturmuster?

Ein Architekturmuster ist die Beschreibung einer Systemorganisation, die erfolgreich in verschiedenen Softwaresystemen eingesetzt wurde.

Muster sind Entdeckungen, keine Erfindungen.

Warum Muster verwenden?

1. Bewährt: Tausende Systeme haben diese Ansätze validiert
2. Kommunizierbar: "Wir verwenden MVC" vermittelt sofort Struktur
3. Analysierbar: Bekannte Muster haben bekannte Kompromisse
4. Wiederverwendbar: Framework-Unterstützung, Dokumentation, Community-Wissen

Drei Kategorien von Architekturmustern

Heute erkunden wir ein Muster aus jeder Kategorie.

Schnellumfrage: Welche Kategorie interessiert Sie am meisten?

Hand heben oder den Umfrage-Link nutzen!

Kategorie 1: Interaktive Systeme

Model-View-Controller (MVC)

Model-View-Controller (MVC)

MVC-Komponenten-Verantwortlichkeiten

Warum MVC?

MVC in Django (Python)

Hinweis: Django verwendet MTV (Model-Template-View) Terminologie, nicht MVC. Djangos "View" fungiert als Controller!

# models.py — Model (wie bei MVC)
class RoadProfile(models.Model):
    name = models.CharField(max_length=100)
    data = models.JSONField()

# views.py — Django "View" = MVC Controller (verarbeitet Anfragen)
def profile_detail(request, profile_id):
    profile = RoadProfile.objects.get(id=profile_id)
    return render(request, 'profile.html', {'profile': profile})

# templates/profile.html — Django "Template" = MVC View (Darstellung)
<h1>{{ profile.name }}</h1>

MVC in Flask (Python)

# models.py (Model)
@dataclass
class RoadProfile:
    id: str
    name: str
    coordinates: list[tuple[float, float]]

# routes.py (Controller)
@app.route('/profiles/<profile_id>')
def show_profile(profile_id):
    profile = ProfileRepository.get(profile_id)
    return render_template('profile.html', profile=profile)

# templates/profile.html (View) - Jinja2-Template

Think-Pair-Share: MVC in Ihrer Erfahrung

Diskussionsfragen:

1. Können Sie Model, View, Controller in Apps identifizieren, die Sie gebaut haben?
2. Haben Sie Apps gesehen, in denen Belange vermischt waren? Welche Probleme entstanden?

Road Profile Viewer: MVC anwenden

Model (models/profile.py):

class RoadProfile(BaseModel):
    """Domain-Model - weiß nichts über UI oder Speicherung."""
    id: str
    name: str
    x_coordinates: list[float]
    y_coordinates: list[float]

    def max_slope(self) -> float:
        """Geschäftslogik lebt im Model."""
        ...

Road Profile Viewer: View-Komponente

View (presentation/charts.py):

def create_profile_figure(profile: RoadProfile) -> go.Figure:
    """Reine Visualisierung - keine Geschäftslogik."""
    return go.Figure(
        data=go.Scatter(
            x=profile.x_coordinates,
            y=profile.y_coordinates,
            mode='lines', name=profile.name
        ),
        layout=go.Layout(title=f"Straßenprofil: {profile.name}")
    )

Road Profile Viewer: Controller-Komponente

Controller (presentation/callbacks.py):

@callback(
    Output('profile-chart', 'figure'),
    Input('profile-dropdown', 'value')
)
def update_chart(profile_id: str):
    """Controller: koordiniert Model und View."""
    if not profile_id:
        return go.Figure()  # Leere Figur

    profile = repository.get(profile_id)  # Model holen
    return create_profile_figure(profile)  # View erstellen

Erreichte MVC-Vorteile

Mit sauberer MVC-Trennung:

• RoadProfile kann ohne Dash getestet werden
• Charts können in anderen Kontexten wiederverwendet werden (PDF-Export, etc.)
• Callbacks sind schlank — nur Koordination, keine Geschäftslogik

Das Model weiß nichts über die View.
Die View weiß nichts über den Controller.
Alle sprechen mit dem Model.

Kategorie 2: Systemstruktur

Schichtenarchitektur

Schichtenarchitektur organisiert Code in horizontale Schichten, wobei jede Schicht nur von der darunterliegenden Schicht abhängt.

  ┌─────────────────────────────────┐
  │     Präsentationsschicht        │  ← Benutzeroberfläche
  └─────────────────────────────────┘
                  │ hängt ab von
                  ▼
  ┌─────────────────────────────────┐
  │       Geschäftsschicht          │  ← Domänenlogik
  └─────────────────────────────────┘
                  │ hängt ab von
                  ▼
  ┌─────────────────────────────────┐
  │      Datenzugriffsschicht       │  ← Datenbankoperationen
  └─────────────────────────────────┘

Schichtenarchitektur: Schlüsselregeln

Die drei goldenen Regeln:

1. Nur Abwärts-Abhängigkeiten: Präsentation → Geschäft → Daten

2. Keine Schichten überspringen: Präsentation sollte NICHT direkt Daten aufrufen

3. Schichten sind kohäsiv: Aller UI-Code in Präsentation, alle Domänenlogik in Geschäft

Warum? Änderungen in einer Schicht kaskadieren nicht durch das gesamte System.

Schicht-Verantwortlichkeiten

Netflix: Ein Praxisbeispiel

Netflix demonstriert Schichtenprinzipien im großen Maßstab:

┌─────────────────────────────────────────────────────────┐
│  PRÄSENTATION: Web-UI, Mobile Apps, TV Apps, API Gateway│
└─────────────────────────────────────────────────────────┘
                            │
┌─────────────────────────────────────────────────────────┐
│  GESCHÄFT: User Service, Content Service, Recommendation│
└─────────────────────────────────────────────────────────┘
                            │
┌─────────────────────────────────────────────────────────┐
│  DATEN: Cassandra, MySQL, ElasticSearch, S3             │
└─────────────────────────────────────────────────────────┘

Netflix: Präsentationsschicht

Jeder Präsentations-Client kann unabhängig aktualisiert werden!

Netflix: Geschäftsschicht (Microservices)

Jeder Service kann unabhängig skaliert werden basierend auf Bedarf!

Netflix: Datenschicht

Wichtige Erkenntnis: Verschiedene Datenspeicher für verschiedene Bedürfnisse!

Schichtenarchitektur: Wichtige Vorteile

Jede Schicht kann sich unabhängig weiterentwickeln.

Road Profile Viewer: Aktueller Zustand (Vermischte Belange)

@app.callback(...)
def update_chart(profile_id):
    if not profile_id:
        return {}  # UI-Logik

    conn = sqlite3.connect('profiles.db')  # Datenzugriff
    cursor = conn.execute('SELECT * FROM profiles WHERE id = ?', (profile_id,))
    row = cursor.fetchone()

    x_coords = json.loads(row[1])  # Geschäftslogik
    y_coords = json.loads(row[2])
    max_slope = calculate_max_slope(x_coords, y_coords)

    return create_figure(x_coords, y_coords, max_slope)  # Wieder UI

Problem: Alle Schichten in einer Funktion vermischt!

Road Profile Viewer: Datenschicht

data_access/repositories.py:

class ProfileRepository:
    def __init__(self, db_path: str = 'profiles.db'):
        self.db_path = db_path

    def get(self, profile_id: str) -> Profile | None:
        conn = sqlite3.connect(self.db_path)
        cursor = conn.execute(
            'SELECT * FROM profiles WHERE id = ?', (profile_id,)
        )
        row = cursor.fetchone()
        return Profile.from_row(row) if row else None

Road Profile Viewer: Geschäftsschicht

business/services.py:

class ProfileService:
    def __init__(self, repository: ProfileRepository):
        self.repository = repository

    def get_profile_with_analysis(self, profile_id: str) -> dict:
        profile = self.repository.get(profile_id)
        if not profile:
            raise ProfileNotFoundError(profile_id)

        return {
            'profile': profile,
            'max_slope': self._calculate_max_slope(profile),
        }

Road Profile Viewer: Präsentationsschicht

presentation/callbacks.py:

service = ProfileService(ProfileRepository())

@app.callback(...)
def update_chart(profile_id):
    if not profile_id:
        return empty_figure()

    try:
        data = service.get_profile_with_analysis(profile_id)
        return create_figure(data)
    except ProfileNotFoundError:
        return error_figure("Profil nicht gefunden")

Sauber! Jede Schicht hat eine Verantwortlichkeit.

Think-Pair-Share: Wo würden Sie Caching hinzufügen?

Diskutieren Sie:

1. In welcher Schicht sollte der Cache leben?
2. Sollte die Geschäftsschicht vom Cache wissen?
3. Wie würden Sie es implementieren, ohne andere Schichten zu ändern?

2 Minuten nachdenken, 2 Minuten zu zweit, dann teilen!

Kategorie 3: Verteilte Systeme

Client-Server & Microservices

Client-Server-Architektur

  ┌──────────────┐
  │   Client 1   │ ──────┐
  │ (Webbrowser) │       │
  └──────────────┘       │
                         ▼
  ┌──────────────┐   ┌──────────┐   ┌──────────┐
  │   Client 2   │ → │  Server  │ → │ Datenbank│
  │ (Mobile App) │   │  (Web)   │   └──────────┘
  └──────────────┘   └──────────┘
                         ▲
  ┌──────────────┐       │
  │   Client 3   │ ──────┘
  │(Desktop-App) │
  └──────────────┘

Client-Server-Eigenschaften

Road Profile Viewer ist bereits Client-Server:

• Client: Webbrowser mit JavaScript/Dash-Frontend
• Server: Python Dash/Flask-Prozess verarbeitet Callbacks

Microservices-Architektur

Microservices zerlegen ein System in kleine, unabhängig deploybare Services:

         ┌─────────────────┐
         │   API Gateway   │
         └────────┬────────┘
      ┌───────────┼───────────┐
      ▼           ▼           ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│   User   │ │  Profil  │ │ Analyse  │
│ Service  │ │ Service  │ │ Service  │
└────┬─────┘ └────┬─────┘ └────┬─────┘
     ▼            ▼            ▼
  [User DB]   [Profil DB]   [Cache]

Monolith vs. Microservices

Amazons Zwei-Pizza-Teams

2002 verfügte Jeff Bezos:

"Alle Teams müssen ihre Funktionalität über Service-Schnittstellen bereitstellen."

Die "Zwei-Pizza-Team"-Regel: Teams klein genug, um mit zwei Pizzen satt zu werden.

Ergebnis: Amazon Web Services — ursprünglich interne Infrastruktur, jetzt ein 80+ Milliarden Dollar Geschäft.

Wann Microservices einsetzen

Road Profile Viewer: Bleibt beim Monolith! Ihr habt 3 Entwickler und eine einfache Domäne.

Schnellumfrage: Monolith oder Microservices?

Szenario: Euer Road Profile Viewer Team wächst von 3 auf 30 Entwickler. Ihr habt jetzt 5 Feature-Teams, die an verschiedenen Teilen arbeiten.

AWS Cloud-Architektur

Cloud-Plattformen bieten Bausteine für verteilte Architekturen:

Users → CloudFront (CDN) → Load Balancer → ECS/Fargate → RDS
        (Edge Cache)       (Routing)      (Container)   (Datenbank)

Für Road Profile Viewer (Zukunft):

• Render.com oder Railway.app — einfaches PaaS, kostenlose Stufe
• Supabase — verwaltetes PostgreSQL mit kostenloser Stufe

Ihr braucht keine AWS-Komplexität für ein Studentenprojekt!

Muster auf Road Profile Viewer anwenden

Vom aktuellen Zustand zur weiterentwickelten Architektur

Aktueller Zustand: Vom Monolith zu Modulen

In Vorlesung 4 (Refactoring) haben wir eine monolithische main.py in Module aufgeteilt:

road-profile-viewer/
├── src/
│   ├── geometry.py       # Strahl-Schnitt-Berechnungen
│   ├── road.py           # Profil-Generierung
│   ├── visualization.py  # Chart-Erstellung
│   └── main.py           # Anwendungs-Einstiegspunkt
└── tests/

Guter Start! Aber wir können mit einer echten Schichtenarchitektur weitergehen.

Vorgeschlagene weiterentwickelte Architektur

road-profile-viewer/
├── src/
│   ├── domain/                    # Kern-Geschäftskonzepte
│   │   ├── models.py              # RoadProfile, Measurement
│   │   └── services.py            # GeometryCalculator
│   │
│   ├── infrastructure/            # Externe Systeme
│   │   └── repositories.py        # ProfileRepository
│   │
│   ├── presentation/              # Benutzeroberfläche
│   │   ├── callbacks.py           # Controller
│   │   └── charts.py              # Views
│   │
│   └── api/                       # Optional: REST API
│       └── routes.py              # FastAPI-Endpunkte

Eine REST-API-Schicht hinzufügen

Warum eine API, wenn Dash bereits funktioniert?

• Mehrere Frontends: Gleiches Backend für Web, Mobile, CLI
• Testen: APIs sind einfacher zu testen als UI-Callbacks
• Integration: Andere Systeme können auf eure Daten zugreifen

@app.get("/api/profiles/{profile_id}")
def get_profile(profile_id: str) -> ProfileResponse:
    profile = repository.get(profile_id)
    if not profile:
        raise HTTPException(status_code=404)
    return ProfileResponse(**profile.dict())

Zukünftige Skalierbarkeit

Falls ihr Road Profile Viewer jemals skalieren müsst:

Die Schichtenarchitektur macht Änderungen lokal!

Interaktive Übung: Das nächste Feature entwerfen

Beantwortet zu zweit:

1. Zu welcher Schicht gehört die PDF-Generierung?
2. Braucht es einen neuen Service in der Geschäftsschicht?
3. Wie würdet ihr es bereitstellen (Button im UI? API-Endpunkt? Beides?)
4. Welche bestehenden Komponenten würdet ihr wiederverwenden?

5 Minuten, dann diskutieren wir!

Architektur und Agile

Zusammenarbeiten

Der scheinbare Konflikt

Manche Entwickler glauben, Agile und Architektur stehen im Konflikt:

Beide Extreme sind falsch.

Emergente Architektur in Scrum

Der agile Ansatz: Emergentes Design mit absichtlicher Struktur.

1. Genug Entscheidungen treffen, um zu starten: Sprache, Framework, Grundstruktur wählen

2. Funktionierende Software implementieren: Echte Features bauen, keine hypothetische Infrastruktur

3. Refactorn, wenn Muster entstehen: Bei Duplikation umstrukturieren

4. Entscheidungen regelmäßig überprüfen: Sprint-Retros können technische Schulden adressieren

Technische Spikes

Ein technischer Spike ist eine zeitbegrenzte Untersuchung zur Reduktion von Unsicherheit.

Beispiel-Spike-Story:

Als Entwickler
möchte ich PostgreSQL vs SQLite für unsere Datenbank untersuchen
damit wir eine informierte Entscheidung treffen können

Zeitlimit: Maximal 2 Tage

Nach dem Spike: Eine informierte architektonische Entscheidung treffen, kein Raten.

Zusammenfassung

Kernaussagen

Zusammenfassungstabelle

Kernaussagen

1. Muster sind bewährte Lösungen — MVC, Schichtenarchitektur und Client-Server lösen wiederkehrende Probleme

2. MVC trennt Belange — Model kennt Daten, View kennt Anzeige, Controller koordiniert

3. Schichten schaffen Grenzen — Abhängigkeiten fließen nur abwärts

4. Microservices sind nicht immer die Antwort — Kleine Teams profitieren von gut strukturierten Monolithen

5. Architektur entwickelt sich mit Agile — Einfach starten, refactoren wenn Muster entstehen

Reflexionsfragen

1. Muster-Identifikation: Welchem Muster folgt euer Road Profile Viewer derzeit?

2. Schicht-Zuordnung: Zu welcher Schicht gehört jede eurer Python-Dateien?

3. Abhängigkeitsrichtung: Zeigen alle eure Imports "abwärts"?

4. Skalierungs-Trigger: Welche Metrik würde euch sagen, dass es Zeit ist, von SQLite zu PostgreSQL zu wechseln?

Was kommt als Nächstes: Auf euer Projekt anwenden

Eure Aktionspunkte:

1. Aktuelles Muster identifizieren: Welchem Muster folgt euer Code (wenn überhaupt)?

2. Schichten zuordnen: Welcher Code ist Präsentation? Geschäft? Datenzugriff?

3. Eine Schicht refactoren: Den unordentlichsten Bereich wählen und Trennung anwenden

4. Architektur dokumentieren: Eine einfache ARCHITECTURE.md erstellen

5. API in Betracht ziehen: Würde eine REST-API eurem Projekt nützen?

Weiterführende Literatur

Bücher:

• Ian Sommerville: Software Engineering (Kapitel 6)
• Robert C. Martin: Clean Architecture
• Martin Fowler: Patterns of Enterprise Application Architecture

Online:

• Martin Fowler über MVC
• Netflix Tech Blog
• The Twelve-Factor App