Seminar Phoenix Framework – Architektur mit Contexts und modularen Grenzen

Das Seminar vermittelt eine wartbare Phoenix-Architektur mit fachlich geschnittenen Contexts, stabilen öffentlichen APIs und kontrollierten Abhängigkeiten. Bestehende Anwendungen werden schrittweise von webzentrierter Struktur zu klaren Domänenmodulen weiterentwickelt.

Inhaltsübersicht

• Seminarprofil, Zielgruppe und Voraussetzungen
• Lernziele
• Schrittweise Seminarinhalte
• Praxisprojekt
• Methodik

Zielgruppe

Softwarearchitekten, Senior-Entwickler, technische Teamleitungen und verantwortliche Maintainer größerer Phoenix-Anwendungen

Voraussetzungen

Gute Elixir- und Phoenix-Kenntnisse sowie Erfahrung mit Ecto und automatisierten Tests

Lernziele

• Fachliche Context-Grenzen belastbar bestimmen
• Öffentliche APIs und interne Implementierungsdetails trennen
• Abhängigkeiten, Transaktionen und Ereignisse beherrschbar gestalten
• Monolith, Umbrella und verteilte Struktur sachgerecht bewerten

Seminarinhalte

1. Architekturziele und Qualitätsmerkmale

1. Schritt 1: Änderungsgründe, Kopplung und Kohäsion der bestehenden Anwendung erfassen.
2. Schritt 2: Wartbarkeit, Testbarkeit und Betriebsanforderungen priorisieren.
3. Schritt 3: Messbare Architekturregeln für das Praxisbeispiel festlegen.

2. Fachliche Context-Grenzen

1. Schritt 1: Geschäftsfähigkeiten und zentrale Begriffe identifizieren.
2. Schritt 2: Datenbesitz und Verantwortlichkeiten einem Context zuordnen.
3. Schritt 3: Unklare Schnittmengen durch konkrete Anwendungsfälle auflösen.

3. Öffentliche Context-APIs

1. Schritt 1: Anwendungsfälle als kleine, intentionale Funktionsschnittstellen formulieren.
2. Schritt 2: Ecto-Schemas und interne Query-Details vor Aufrufern verbergen.
3. Schritt 3: Rückgabewerte und Fehlerkontrakte einheitlich gestalten.

4. Webschicht und Domänenlogik

1. Schritt 1: Controller und LiveViews auf Eingabe, Orchestrierung und Darstellung begrenzen.
2. Schritt 2: Validierung zwischen Transport-, Anwendungs- und Datenebene unterscheiden.
3. Schritt 3: Abhängigkeiten über klar benannte Context-Funktionen führen.

5. Context-übergreifende Abläufe

1. Schritt 1: Mehrschrittige Geschäftsprozesse einem verantwortlichen Orchestrator zuordnen.
2. Schritt 2: Transaktionsgrenzen und Kompensationsbedarf bestimmen.
3. Schritt 3: Synchrone Aufrufe, Nachrichten und PubSub-Ereignisse gezielt auswählen.

6. OTP und Prozessgrenzen

1. Schritt 1: Zustandslose Module von langlebigen Prozessen trennen.
2. Schritt 2: Supervision, Registry und Prozessverantwortung modellieren.
3. Schritt 3: Globale Zustände und unnötige GenServer vermeiden.

7. Monolith, Umbrella und Verteilung

1. Schritt 1: Modularen Monolithen als Ausgangspunkt bewerten.
2. Schritt 2: Umbrella-Anwendungen anhand realer Abhängigkeitsgrenzen prüfen.
3. Schritt 3: Verteilung nur für konkrete Skalierungs- oder Isolationsziele einsetzen.

8. Architekturtests und Refactoring

1. Schritt 1: Abhängigkeiten und öffentliche APIs mit Tests absichern.
2. Schritt 2: Eine problematische Funktionalität schrittweise in Contexts überführen.
3. Schritt 3: Migrationsschritte so planen, dass die Anwendung jederzeit lauffähig bleibt.

Praxisprojekt

Refactoring einer gewachsenen Beispielanwendung in fachliche Contexts mit dokumentierten APIs, transaktionalen Abläufen, Ereignissen und automatisierten Architekturprüfungen.

Methodik

Kurze fachliche Einführungen wechseln mit Live-Demonstrationen, geführten Implementierungsschritten, eigenständigen Übungen, Code-Reviews, Fehlerszenarien und überprüfbaren Zwischenständen. Sämtliche Übungen bauen auf einem konsistenten Referenzprojekt auf.