Infografik zu Phase 1 der heat-conduction-app. Dargestellt ist der Weg vom fachlichen Ingenieurmodell zur produktiven Webanwendung. Die sieben Umsetzungsschritte sind durch Symbole und Pfeile verbunden: Fachliches Modell, Softwarearchitektur, Projektgerüst, Businesslogik, Benutzeroberfläche, Persistenz sowie Deployment und Betrieb. Die Grafik verwendet einen Farbverlauf von Orange nach Blau als Symbol für den Übergang von Engineering zu Softwareentwicklung. Unten steht der Titel "Vom Ingenieurmodell zur produktiven Webanwendung - Referenzprojekt: heat-conduction-app"

Phase 1 abgeschlossen - vom Ingenieurmodell zur produktiven Webanwendung

heat-conduction-app: Referenzprojekt für moderne Backend- und Webentwicklung

Engineering → Softwareentwicklung Softwarearchitektur Backend-Entwicklung Webanwendung heat-conduction-app

← Zurück zur Übersicht | ← Meilenstein 5 - Deployment

Einleitung

Die heat-conduction-app läuft inzwischen produktiv auf einem VPS und ist öffentlich erreichbar. Damit ist die erste Projektphase abgeschlossen.

Ziel dieser Phase war nicht die Entwicklung eines vollständigen Produkts, sondern die schrittweise Umsetzung eines lauffähigen Prototyps. Im Mittelpunkt stand die Frage:

Wie lässt sich Ingenieurwissen in eine moderne, wartbare Softwarelösung überführen?

Zu jedem Teilaspekt dieser Umsetzung habe ich einen Blogartikel veröffentlicht der sich umfassend damit beschäftigt. An dieser Stelle möchte ich einen Überblick über die Schritte und ihren jeweiligen Schwerpunkt geben.

Projektkontext

Dieser Artikel ist Teil zur Serie zur heat-conduction-app. Der aktuelle Stand ist im Repository verfügbar, die Anwendung läuft produktiv unter einer eigenen Subdomain.

1. Fachliches Verständnis vor Technologie

Vom Fourierschen Gesetz zur Softwarelogik

Grafische Zerlegung einer Fourier-Wärmeleitungsdarstellung in fünf funktionale Bausteine: Domänenmodell, Berechnungslogik, Eingabe, Ausgabe und Orchestrierung.
Von der physikalischen Darstellung zur Softwarestruktur: Die Grafik zeigt, wie sich ein physikalisches Modell (hier die 1D-Wärmeleitung nach Fourier) in fünf funktionale Bausteine zerlegen lässt. Diese Bausteine bilden eine domänenspezifische Denkstruktur zur Überführung von Ingenieurwissen in Software - unabhängig von Technologie und Architektur.

Ausgangspunkt ist der Problemraum mit dem fachlichen Thema und der Aufgabe dieses zu abstrahieren.

Dazu wird die Wärmeleitung zunächst als fachliches Modell betrachtet und teilweise vereinfacht. Und anschließend in funktionale Bausteine zerlegt. Dadurch entsteht eine Trennung zwischen Domänenwissen und technischer Umsetzung.

Der wichtigste Gedanke dieser Phase:

Fachliche Modelle sollten unabhängig von Frameworks beschrieben werden können.

Diese Abstraktion bildet die Grundlage für spätere Erweiterungen und erleichtert den Wechsel zwischen Technologien.

2. Architektur als Übersetzungsschicht

Von funktionalen Bausteinen zur Webanwendung

Im nächsten Schritt wird aus den fachlichen Bausteinen eine Softwarearchitektur abgeleitet.

Dabei steht weniger ein konkretes Framework als vielmehr die folgenden Fragen im Mittelpunkt:

  • Welche Verantwortlichkeiten existieren?
  • Wie werden sie voneinander getrennt?
  • Wie kann die Anwendung schrittweise wachsen?

Das dafür verwendete 4-Phasen-Modell dient als Orientierung für die weitere Entwicklung und ist bewusst technologieunabhängig angelegt.

3. Das Projektgerüst als Fundament

Struktur schafft Erweiterbarkeit

Grafik zur Einordnung eines Softwareprojekts von Konzept zu Code. Drei übereinander angeordnete Ebenen zeigen den Übergang vom Problemraum zum Lösungsraum und zur Umsetzung. Oben der Problemraum mit "Ingenieurproblem" und "Funktionale Bausteine", in der Mitte der Lösungsraum mit "4-Phasen-Modell", "Softwarearchitektur" und "Software-Stack", unten die Umsetzungsebene mit "Implementierungsebene", "Applikationsstruktur" und "Projektsetup". Ein Pfeil rechts markiert die Bewegung von oben nach unten.
Von Konzept zu Code: Einordnung der Implementierungsebene innerhalb des Gesamtzusammenhangs aus Problemraum, Lösungsraum und konkreter Umsetzung.

Erst danach beginnt die eigentliche Implementierung.

Mit dem Projektgerüst werden Architekturentscheidungen in eine konkrete Verzeichnis- und Applikationsstruktur überführt.

Der Fokus liegt auf:

  • klaren Verantwortlichkeiten
  • reproduzierbarem Setup
  • Testbarkeit
  • Erweiterbarkeit

An dieser Stelle wird Architektur erstmals in ausführbaren Code übersetzt.

4. Die Fachlogik wird ausführbar

Testgetrieben zur ersten Berechnung

Mit der Implementierung der Wärmeleitungsberechnung entsteht das eigentliche Herzstück der Anwendung.

Der Schwerpunkt liegt auf Test Driven Development und einer klaren Trennung zwischen:

  • Domänenlogik
  • HTTP-Kommunikation
  • Infrastruktur

Damit existiert erstmals eine fachlich nutzbare Anwendungskomponente.

5. Von der Berechnung zur Anwendung

Benutzeroberfläche und Interaktion

In diesem Schritt erhält die Anwendung eine grafische Oberfläche.

Die UI wird in der ersten Projektphase bewusst schlank gehalten. Im Vordergrund stehen:

  • Server Side Rendering
  • Formularverarbeitung
  • Post-Redirect-Get Pattern
  • Internationalisierung

Die Fachlogik wird dadurch für Anwender mittels Browser zugänglich, ohne bestehende Architektur zu verändern.

6. Persistenz

Die Anwendung bekommt ein Gedächtnis

Mobile Ansicht des Eingabeformulars der heat-conduction-app mit Dropdown zur Materialauswahl und dynamischer Anzeige der zugehörigen Wärmeleitfähigkeit.
Eingabeformular in der mobilen Ansicht. Das Material wird über ein Dropdown ausgewählt, während der zugehörige Wärmeleitwert clientseitig per JavaScript automatisch angezeigt und für die Berechnung verwendet wird.

Mit der Datenbankintegration entsteht eine Persistenzschicht und dem Fokus auf der Trennung der Verantwortlichkeiten:

Database
  ↓
Repository
  ↓
Route
  ↓
Service
  ↓
Result

Die Berechnungslogik bleibt unabhängig von der Datenhaltung.

Diese Entkopplung ermöglicht eine spätere Erweiterungen ohne tiefgreifende Änderungen am Fachkern.

7. Deployment und Betrieb

Vom Entwicklungsprojekt zum System

Architekturdiagramm eines produktiven Webanwendungs-Deployments. Browser, Laptop und Smartphone greifen über HTTPS auf einen VPS zu. Eine Firewall filtert eingehende Anfragen und leitet sie an einen Reverse Proxy innerhalb eines Docker-Netzwerks weiter. Der Reverse Proxy terminiert TLS und verteilt interne HTTP-Anfragen an mehrere containerisierte Application Services. Die Kommunikation zwischen Client und Server erfolgt verschlüsselt über HTTPS, die interne Kommunikation innerhalb des Docker-Netzwerks über HTTP.
Vom lokalen Container-Setup zum produktiven Betrieb: Reverse Proxy, Docker-Netzwerk und HTTPS bilden die Grundlage einer reproduzierbaren Deployment-Architektur.

Der letzte Schritt besteht darin, die Anwendung produktiv bereitzustellen.

Neben Docker und Deployment rücken Themen in den Vordergrund, die eher ausserhalb der klassischen Softwareentwicklung liegen:

  • Reverse Proxy
  • HTTPS
  • Linux-Betrieb
  • Monitoring
  • Logging
  • Sicherheit

Damit wird aus einem lokalen Entwicklungsprojekt ein öffentlich erreichbares System.

Fazit

Die Umsetzung der ersten Projektphase lässt sich auf folgende Schritte reduzieren:

Fachliches Modell
  ↓
Softwarearchitektur
  ↓
Projektgerüst
  ↓
Businesslogik
  ↓
Benutzeroberfläche
  ↓
Persistenz
  ↓
Deployment & Betrieb

Jeder dieser Schritte verfolgt einen eigenen Schwerpunkt. Gemeinsam zeigen sie jedoch einen Grundsatz moderner Softwareentwicklung:

Erweiterbarkeit entsteht vor allem durch eine saubere Trennung von Verantwortlichkeiten. Technologien und Frameworks können diese Struktur unterstützen, ersetzen sie aber nicht.

Die heat-conduction-app dient dabei weniger als fachliches Wärmeleitungswerkzeug, sondern als Referenzprojekt für die Entwicklung technischer Webanwendungen.

Mit dem produktiven Deployment ist Phase 1 abgeschlossen. Die erarbeiteten Architekturprinzipien sind jedoch nicht auf Python und Flask beschränkt. Genau deshalb werde ich die nächsten Schritte voraussichtlich im Java- und Spring Boot-Umfeld fortführen und herausarbeiten, wie sich dieselben Architekturgedanken mit einem anderen Technologie-Stack umsetzen lassen.

Feedback, Fragen oder Anregungen sind jederzeit willkommen, gerne per Email oder auch auf LinkedIn.