Seminar Flask Anwendungsarchitektur mit Blueprints und Application Factory

Wachsende Flask-Projekte benötigen früh eine belastbare Struktur. Das Seminar zeigt, wie Anwendungsobjekt, Konfiguration, Erweiterungen, fachliche Module und Datenzugriffe so zusammengesetzt werden, dass Entwicklung, Test und Betrieb voneinander entkoppelt bleiben.

Im Mittelpunkt steht die schrittweise Umwandlung einer zunächst monolithischen Anwendung in ein installierbares Paket mit Application Factory, Blueprints und klaren Servicegrenzen. Architekturentscheidungen werden unmittelbar durch Tests überprüft.

Inhaltsübersicht

1. Application Factory und mehrfache Instanzen
2. Blueprints und modulare Funktionsbereiche
3. Paketstruktur und interne Abhängigkeiten
4. Konfiguration und Erweiterungsinitialisierung
5. Service-, Repository- und Domänenschichten
6. pytest-Struktur und Fixtures
7. Integrations- und Migrationstests
8. Praxisprojekt und Wissenssicherung

Lernziele

• Eine Flask-Anwendung über eine Factory reproduzierbar zusammensetzen.
• Fachliche Funktionsbereiche mit Blueprints sauber abgrenzen.
• Geschäftslogik von HTTP und Persistenz trennen.
• Konfiguration und Erweiterungen ohne Importseiteneffekte initialisieren.
• Architekturregeln mit Unit- und Integrationstests absichern.

Zielgruppe

Python-Entwickler, Softwarearchitekten, technische Projektleiter und Teams, die bestehende oder neue Flask-Anwendungen dauerhaft wartbar strukturieren müssen.

Voraussetzungen

Sichere Python-Grundlagen sowie erste Erfahrung mit Flask-Routen, Requests und Templates. Grundkenntnisse automatisierter Tests sind hilfreich.

Seminarinhalte

1. Application Factory und mehrfache Instanzen

Die Anwendung wird in einer Fabrikfunktion zusammengesetzt, damit Konfiguration, Tests und Varianten beherrschbar bleiben.

1. Schritt 1: create_app mit klarer Reihenfolge für Konfiguration, Erweiterungen, Blueprints und Hooks aufbauen.
2. Schritt 2: Testkonfiguration als Mapping übergeben und Dateizugriffe während des Imports vermeiden.
3. Schritt 3: Mehrere Anwendungsinstanzen mit getrennten Einstellungen innerhalb eines Prozesses erzeugen.
4. Schritt 4: Factory-Erkennung über die Flask-Kommandozeile und Produktionsserver prüfen.

2. Blueprints und modulare Funktionsbereiche

Große Anwendungen werden entlang fachlicher Verantwortlichkeiten in registrierbare Komponenten zerlegt.

1. Schritt 1: Blueprint-Grenzen nach Domäne statt ausschließlich nach technischen Schichten festlegen.
2. Schritt 2: Routen, Templates, statische Dateien und Fehlerbehandlung einem Blueprint zuordnen.
3. Schritt 3: URL-Präfixe, Unterdomänen und Endpunktnamen konsistent konfigurieren.
4. Schritt 4: Registrierungsreihenfolge, mehrfache Registrierung und gemeinsame Hooks testen.

3. Paketstruktur und interne Abhängigkeiten

Module werden so angeordnet, dass Importzyklen, globale Zustände und unklare Verantwortlichkeiten vermieden werden.

1. Schritt 1: Anwendungspaket, Konfiguration, Blueprints, Services, Modelle und Tests getrennt strukturieren.
2. Schritt 2: Öffentliche Schnittstellen über __init__-Module bewusst begrenzen.
3. Schritt 3: Abhängigkeitsrichtung festlegen und zyklische Importe durch Factory- oder Interface-Muster auflösen.
4. Schritt 4: Paket installierbar machen und Importverhalten in einer frischen Umgebung prüfen.

4. Konfiguration und Erweiterungsinitialisierung

Umgebungsabhängige Werte und Erweiterungen werden früh, eindeutig und ohne Importseiteneffekte eingerichtet.

1. Schritt 1: Defaults, Umgebungsvariablen und geheime Werte in einer nachvollziehbaren Rangfolge laden.
2. Schritt 2: Konfigurationsschlüssel mit Namensräumen versehen und beim Start validieren.
3. Schritt 3: Erweiterungsobjekte ungebunden erzeugen und erst in create_app initialisieren.
4. Schritt 4: Fehlende oder widersprüchliche Einstellungen mit einem kontrollierten Startabbruch behandeln.

5. Service-, Repository- und Domänenschichten

Geschäftslogik wird von HTTP und Persistenz getrennt, damit sie unabhängig testbar und wiederverwendbar bleibt.

1. Schritt 1: View-Funktionen auf Eingabe, Serviceaufruf und Response-Abbildung reduzieren.
2. Schritt 2: Services für Anwendungsfälle und Repositories für Datenzugriffe definieren.
3. Schritt 3: Domänenfehler statt HTTP-Ausnahmen aus tieferen Schichten zurückgeben.
4. Schritt 4: Servicefälle mit Fakes testen und Integrationspfade separat absichern.

6. pytest-Struktur und Fixtures

Tests erhalten wiederverwendbare, klar begrenzte Setups für Anwendung, Client, CLI und Daten.

1. Schritt 1: Testverzeichnisse und Benennung nach pytest-Konventionen anlegen.
2. Schritt 2: App-Fixture mit TESTING-Konfiguration und sauberem Teardown erstellen.
3. Schritt 3: Client-, Runner- und Daten-Fixtures aus der App-Fixture ableiten.
4. Schritt 4: Fixture-Sichtbarkeit und Scope so klein wie möglich halten.

7. Integrations- und Migrationstests

Zusammenspiel von Anwendung, Datenbank, Queue und Fremdsystemadaptern wird in realitätsnahen Umgebungen überprüft.

1. Schritt 1: Testdatenbank mit produktionsnahem Datenbanktyp bereitstellen.
2. Schritt 2: Migrationen vom leeren Schema bis zum aktuellen Stand ausführen.
3. Schritt 3: Transaktionen, Constraints und Adapter gegen lokale Testdienste prüfen.
4. Schritt 4: Tests isolieren, parallelisierbar machen und Ressourcen zuverlässig abbauen.

Praxisprojekt

Eine kompakte Bestandsanwendung wird in mehreren Refactoring-Schritten zerlegt. Am Ende liegen ein installierbares Paket, mehrere Blueprints, eine Application Factory, gekapselte Services und eine ausführbare Testsuite vor.

Methodik

Kurze fachliche Einordnungen wechseln mit Demonstrationen, geführten Umsetzungen, Fehleranalysen und eigenständigen Übungen. Jede größere Änderung wird durch einen Test, eine Diagnose oder eine betriebliche Prüfroutine abgesichert. Die Arbeitsstände werden schrittweise zu einem durchgängigen Beispielprojekt zusammengeführt.