Wie sich das Fouriersche Gesetz in Software übersetzen lässt

Einleitung

Im ersten Teil meines Einführungspost ging es mir um meinen persönlichen Entwicklungsweg vom Diplom-Maschinenbauingenieur hin zu einem Softwareentwickler für Backend- und Webanwendungen mit technischem Fokus. Ein zentrales Element meiner beruflichen Neuorientierung ist die heat-conduction-App, als Referenz- und Portfolioprojekt.

In diesem zweiten Teil möchte ich auf den technischen Kern der heat-conduction-app eingehen, den physikalischen Hintergrund und den Weg von der technischen Formel hin zur Softwarearchitektur. Das Thema Wärmeleitung, oder allgemeiner Wärmetransport, ist physikalisch sehr umfangreich und verdient sicher einen eigenen Artikel, daher konzentriere ich mich auf die vereinfachte stationäre, eindimensionale Form der Wärmeleitung als Einstieg.

Physikalisch-technischer Hintergrund - das 1. Fouriersche Gesetz

Die heat-conduction-app basiert auf einem fundamentalen physikalischen Prinzip: der stationären, eindimensionalen Wärmeleitung durch eine homogene Wand. Dieses Prinzip begegnet uns in vielen technischen Anwendungen und Geräten.

Zwischen den beiden Wandseiten mit den Temperaturen \(\vartheta_1\) und \(\vartheta_2\) fließt Wärme von der warmen zur kälteren Seite. Diese Form des Wärmetransports wird Konduktion oder Wärmeleitung genannt. Sie entsteht durch Energieübertragung auf atomarer Ebene, ohne dass sich das Material selbst bewegt, im Gegensatz zur Konvektion (Wärmeübertragung durch Strömung) oder Strahlung (elektromagentische Übertragung).

Die Grundlage bildet das 1. Fouriersche Gesetz in seiner eindimensionalen, stationären Form:

\[ \dot{Q} = \lambda(\vartheta) \cdot \frac{ \mathrm{d}\vartheta}{\mathrm{d}r} \cdot A(r) \]

mit den Vereinfachungen:

1. Eindimensionale Wärmeleitung (1D) - Es findet nur Wärmetransport in einer Richtung statt
2. Stationärer Zustand - Temperaturen und Wärmeströme ändern sich nicht über die Zeit

Dabei gilt:

• \(\dot{Q}\) = übertragene Wärmestromleistung
• \(\lambda(\vartheta)\) = temperaturabhängige Wärmeleitfähigkeit des Materials
• \(\frac{ \mathrm{d}\vartheta}{\mathrm{d}r}\) = Temperaturgradienten
• \(A(r)\) = Querschnittsfläche entlang des Wegs \(r\)

Um die Wärmeleitung anschaulich und nachvollziehbar in Software umzusetzen, werden zwei weitere Vereinfachungen vorgenommen:

3. Konstante Wärmeleitfähigkeit - \(\lambda\) unabhängig von der Temperatur
4. Konstante Fläche - Querschnitt \(A\) über den Weg \(r\) konstant

Unter diesen Annahmen vereinfacht sich das Fourier-Gesetz zu einer linearen Gleichung:

\[ \dot{Q} = \frac{\lambda \cdot A \cdot (T_1 - T_2)}{d} \]

Diese Gleichung beschreibt die Wärmeleitung durch eine Wand mit der Dicke \(d\) zwischen den Temperaturen \(T_1\) und \(T_2\).

Warum “nur” die Wärmeleitung durch eine Wand betrachtet wird

Auf den ersten Blick mag die Umsetzung dieser einfachen Gleichung unscheinbar wirken. Komplexere thermische Berechnungen, wie Konvektion, Strahlung, mehrschichtige Systeme oder transiente Modelle, liegen nahe und sind im echten Ingenieuralltag oft entscheidend.

Für die heat-conduction-app geht es jedoch nicht um die vollständige physikalische Tiefe, sondern um ein Referenzprojekt für modulare Softwarearchitektur. Die 1D-stationäre Wärmeleitung dient hier als klar definierte, mathematisch einfache Basis, auf der sich Architekturprinzipien, modulare Struktur und Softwarelogik demonstrieren lassen.

Diese Basis lässt sich später leicht erweitern und skalieren, sie ist das Minimum Viable Product (MVP) der App. Aus Erfahrung entstehen komplexere Tools ohnehin iterativ. Sobald eine funktionierende Grundanwendung existiert, wächst der Wunsch nach zusätzlichen Funktionen. Mit der Zeit kann daraus ein umfangreiches System entstehen und irgendwann steht man vor der Frage, ob man die Aufgaben trennt, Teile auslagert oder über APIs mehrere spezialisierte Apps verbindet.

Die Wärmeleistung durch eine Wand ist also weniger eine inhaltliche Begrenzung, sondern vielmehr ein bewusst gewähltes Fundament, auf dem sich eine nachhaltige Software-Architektur aufbauen lässt.

Von der Formel zur Softwarelogik

Nachdem die technisch-physikalische Aufgabenstellung klar ist, stellt sich die Frage: Wie wird daraus Softwarelogik? An dieser Stelle geht es noch nicht um den konkreten Technologiestack, dieser folgt im nächsten Blogartikel, sondern um die grundsätzliche Übersetzung von Fachlogik in strukturierte, wartbare Software.

Unabhängig von der konkreten Gleichung oder technischen Domäne folgt diese Übersetzung in Software in der Praxis meist einem ähnlichen Muster. Fachliche Größen werden zu Teil eines Domänenmodells, und die eigentliche Berechnung wird als klar abgegrenzte fachliche Service-Logik formuliert.

Im Kern steht eine Funktion, die den Wärmestrom in Abhängigkeit von fünf Größen berechnet: den Temperaturen \(T_1\) und \(T_2\), der Wärmeleitfähigkeit \(\lambda\), der Wanddicke \(d\) und der Fläche \(A\). Diese Größen gehören fachlich zum Domänenmodell, während sich die Berechnung selbst als konzeptionelles, fachliches Service-Modul auffassen lässt, unabhängig von Technologie oder Framework.

Damit diese fachliche Logik nutzbar wird, benötigt sie Eingabedaten. Dafür gibt es in einer modernen Anwendung mehrere Wege:

• Über eine Benutzeroberfläche (Frontend): komfortable und intuitiv, ideal für interaktive Nutzung.
• Über eine textbasierte Schnittstelle (API, z.B. JSON): flexibel und automatisierbar, etwa für Skripte oder andere Anwendungen.
• Über eine Datenbankanbindung: anstelle direkter Eingaben können Materialien gewählt werden, deren Wärmeleitwerte automatisch aus einer hinterlegten Datenbank gezogen werden.

Ebenso wichtig wie die Eingabe ist die Ausgabe der Ergebnisse, entweder als Visualisierung in der Oberfläche oder als strukturierte API-Antwort. Hier reicht die Bandbreite von einfachen Zahlenwerten bis hin zu interaktiven Diagrammen oder Wandmodellen.

An dieser Stelle wird deutlich, um eine scheinbar einfache Gleichung als Webanwendung bereitzustellen, braucht es mehr als nur eine Formel. Notwendig sind klar getrennte Verantwortlichkeiten für Fachlogik, Schnittstellen, Datenhaltung und Darstellung. Gleichzeitig gibt es kein einfaches 1:1 Mapping von der physikalischen Aufgabenstellung zur Softwarearchitektur.

Konzept der funktionalen Bausteine

Um den Weg von der physikalischen Aufgabenstellung zur Software-Applikation systematisch und nachvollziehbar zu gestalten, nutze ich das Konzeot der funktionalen Bausteine. Diese Abstraktionsebene liegt bewusst oberhalb von Physik und Software-Stack, ist aber domänenspezifisch für technische Berechnungssoftware, Ingenieurtools oder wissenschaftliche Anwendungen.

Technische Applikationslogik lässt sich dabei in fünf funktionale Bausteine gliedern:

1. Domänenmodell - Welche fachlichen Objekte und Größen existieren?
2. Berechnungslogik - Wie werden diese Größen fachlich miteinander verknüpft?
3. Eingabeschicht - Wie gelangen konkrete Werte ins System?
4. Ausgabeschicht - Wie werden Ergebnisse dargestellt oder weitergegeben?
5. Orchestrierung - Wie greifen alle Bausteine kontrolliert ineinander?

Diese Bausteine beschreiben keine konkrete Softwarearchitektur und auch kein klassisches Schichtenmodell. Sie bilden vielmehr eine funktionale Denkstruktur, die hilf, Ingenieurwissen systematisch in ein Softwareprojekt zu überführen.

Eine besondere Rolle spielt dabei die Orchestrierung, sie enthält selbst keine fachliche Physik, sondern steuert den Ablauf. Sie nimmt Eingaben entgegen, ruft Berechnungen auf, kombiniert Ergebnisse und übergibt sie an die Ausgabeschicht. Dadurch bleibt die Fachlogik sauber gekapselt und unabhängig von UI, API oder Persistenz.

Je nach Anwendung können diese Bausteine unterschiedlich ausgeprägt oder zusammengefasst sein. Die Inhalte ändern sich, das Grundprinzip und die Struktur bleiben gleich. In diesem Sinne fungiert das Modell als eine Art Übersetzer zwischen Engineering-Domäne und wartbarer Softwarestruktur.

Der nächste Schritt ist dann die Überführung der funktionalen Bausteine in eine technische Softwarearchitektur und die Umsetzung in einem Software-Stack. Genau deshalb ist eine klare Struktur und ein durchdachtes Vorgehen entscheidend. Mein Ansatz folgt dem im ersten Teil vorgestellten 4-Phasen-Modell: Schnelligkeit → Persistenz → Flexibilität → Benutzerfreundlichkeit. Diese Phasen helfen, die Komplexität kontrolliert zu erhöhen und die Anwendung entlang realistischer Anforderungen wachsen zu lassen.

Ausblick auf Teil 3

In diesem zweiten Teil meiner Einführungsreihe lag der Fokus auf der technisch-physikalischen Grundlage, der fachlichen Rechenlogik, die das Fundament jeder technischen Berechnungsapplikation bildet und ihrer Abstraktion in funktionale Bausteine. Gerade bei solchen Anwendungen ist zu Beginn oft noch nicht vollständig klar, welche fachlichen und funktionalen Erweiterungen später hinzukommen werden. Daher ist es wichtig, von Anfang an Flexibilität, Erweiterbarkeit und saubere Trennung von Verantwortlichkeiten mitzudenken.

Genau hier setzt Teil 3 an. Dort stelle ich die konkrete Software-Architektur und den gewählten Technologiestack vor. Wie die App technisch aufgebaut ist, welche Architekturentscheidungen ich getroffen habe und wie sich das 4-Phasen-Modell in der Praxis abbildet.

Der Blog dokumentiert meine Weiterentwicklung und meine Arbeit an diesem Referenzprojekt. Wenn du Anregungen, Rückfragen oder fachlichen Austausch suchst, freue ich mich über eine Nachricht per Email oder eine Vernetzung auf LinkedIn.