Blog

Moderne Softwarearchitektur kämpft oft mit zu starker Kopplung und unklaren Datenmodellen. Im Interview erklärt Michael Sperber, wie funktionale Architektur und domänenspezifische Sprachen helfen, Systeme verständlicher, flexibler und langlebiger zu machen.

 

Du kritisierst in deiner Session zwei zentrale Probleme moderner Softwarearchitektur: mutable State und unzureichende Datenmodellierung. Warum sind genau diese beiden Aspekte so entscheidend für die Qualität von Software?

In der Softwarearchitektur ist Kopplung unser Todfeind, also Abhängigkeiten zwischen Bausteinen, die spätere Änderungen erschweren. Die Hauptquelle von Kopplung in großen Systemen ist mutable State: Ein anderer Baustein hat etwas an einem Objekt geändert, auf das ich zugreife. Das findet meist im Verborgenen statt und hinterlässt keine Spuren – die Reihenfolge muss aber trotzdem genau stimmen, auch in Systemen mit mehreren Threads. Je weniger es also davon gibt, desto besser.

Schlechte Datenmodellierung ist eigentlich ein unnötiges Problem: Wir alle haben schon Software benutzt, der man ansieht, dass alle Daten in ein rechteckiges Tabellenschema gepresst wurden, was aber eigentlich gar nicht so recht passt. Das kommt daher, dass Datenmodellierung oft von unseren Werkzeugen geprägt wird – von Excel und relationalen Datenbanken. Um aus diesen Tabellenschemata auszubrechen, benötigen Softwarearchitekt:innen etwas Vokabular, nämlich Produkte und Summen.

Excel und Datenbanken kennen nur Produkte („eine Adresse hat die Attribute Straße, Postleitzahl und Ort“). Das operative Wort ist hier „und“. Es gibt aber unterschiedliche Formen von Adressen: das kann eine Straßenadresse sein ODER beispielsweise eine Postbox. Eine Postbox hat natürlich ganz andere Attribute. In rechteckigen Schemata werden dann oft die vorhandenen Attribute missbraucht – die Straße ist dann vielleicht das Wort „Packstation“, die Postnummer wird ins „Adresszusatz“-Feld gesteckt. Irgendwann ist alles nur noch verwirrend und braucht eine Anleitung. Das kann man besser machen, indem man bewusst mit Produkten und Summen modelliert.

Wer das ausführlich nachlesen möchte, kann das in dem Blog-Artikel tun, den iSAQB-Kollege Stefan Wehr und ich anlässlich der Aufnahme dieser Themen ins iSAQB-Foundation-Curriculum geschrieben haben: https://funktionale-programmierung.de/2024/11/25/sums-products.html

 

Funktionale Softwarearchitektur setzt auf kontrollierten oder gar keinen mutable State. Welche konkreten Vorteile ergeben sich daraus in der Praxis für Wartbarkeit und Verständlichkeit von Systemen?

Einfach ausgedrückt: Alles wird besser. Durch die geringere Kopplung können die Bausteine funktionaler Architektur oft isoliert betrachtet werden, ohne das ganze Umfeld zu verstehen. Damit ist funktionale Architektur besser wartbar und bleibt auch länger geschmeidig.

Hinzu kommt, dass funktionale Programmiersprachen oft kompaktere Programme ermöglichen, die einen Sachverhalt mit weniger Code auf den Punkt bringen – das erhöht die Verständlichkeit noch weiter.

 

Ein weiterer Fokus liegt auf reichhaltig strukturierten Datenmodellen. Was unterscheidet solche Modelle von klassischen Ansätzen und warum sind sie so wichtig für langlebige Systeme?

Klassische Ansätze reagieren häufig auf neue Anforderungen dadurch, dass das Datenmodell erweitert oder geändert werden muss. Das zieht sich zunächst durch die Datenbank und in der Regel auch durch die anderen Schichten des Systems. Die Attribute werden mehr, die Tabellen werden breiter und alles wird immer schwerfälliger.

In der funktionalen Architektur setzen wir auf sogenannte Kombinatormodelle. Statt jedes Feature einzeln im Datenmodell unterzubringen, sind Kombinatormodelle Baukästen, in denen jeder Baustein viele unterschiedliche Features umsetzen kann. Gute Kombinatormodelle können neue Anforderungen oft gänzlich ohne Erweiterung des Datenmodells abbilden.

Da Kombinatormodelle durch Abstraktion über die reine Fachlichkeit entstehen, eröffnen sie außerdem oft neue Sichtweisen auf die Domäne und Ideen für Features, auf die man ohne solche Modelle gar nicht gekommen wäre.

 

Du betonst die Bedeutung präziser und gut strukturierter Domänenmodelle. Gleichzeitig beschäftigst du dich intensiv mit domänenspezifischen Sprachen. Welche Rolle spielen DSLs dabei, Fachlichkeit noch näher an die Architektur zu bringen?

Gute DSLs sind letztlich eine Fortsetzung guter Modellierung. Schon bei Kombinatormodellen ist es so, dass deren Benutzer:innen es oft so empfinden, dass sie eine neue Sprache an die Hand bekommen. Gegebenenfalls muss noch eine Syntax obendrauf gesetzt werden, fertig ist die DSL.

Durch die Architekturbrille betrachtet können gute DSLs trennen zwischen einer kompakten Formulierung der Fachlichkeit und der technischen Umsetzung darunter – sie tragen also weiter zur Entkopplung bei. Außerdem machen sie noch in höherem Maße als Kombinatormodelle unnötig, dass die Software erweitert oder geändert werden muss, um neue Features umzusetzen. Wir reden in der Architektur davon, „Maintainability“ zu erleichtern, aber der heilige Gral ist natürlich, „Maintenance“ möglichst unnötig zu machen. Dabei helfen DSLs.

 

Domänenspezifische Sprachen gelten als sehr mächtig, sind in der Praxis aber selten. Woran liegt das und welche Ansätze machen ihren Einsatz heute realistischer?

So selten sind sie gar nicht: In vielen Projekten sitzen Konfigurationsdateien, deren Format außer Kontrolle geraten ist, weil sich niemand um das Design so richtig gekümmert hat. Das sind effektiv DSLs, nur eben schlechte. DSLs gut umzusetzen, erfordert – neben Sorgfalt und gutem Geschmack – ein paar Grundkenntnisse aus dem Compilerbau, die viele Entwickler:innen und Architekt:innen nicht mitbringen (oder die entsprechende Vorlesung vergessen haben). Das ist aber recht schnell nachgeholt, zum Beispiel in einer iSAQB-DSL-Schulung.

 

Welche Vorteile bieten DSLs gegenüber klassischen Benutzeroberflächen oder auch KI-basierten Interfaces und in welchen Szenarien entfalten sie ihr größtes Potenzial?

DSLs setzt man dort ein, wo klassische Benutzeroberflächen als Medium überfordert sind, weil sie einfach nicht ausdrucksstark genug sind. KI-basierte Interfaces können gelegentlich Ähnliches leisten wie DSLs, wenn man die KI mit Fachsprache anspricht und sie dann machen lässt. Ob das sinnvoll ist, ist eine Frage der Anforderungen: DSLs können für Präzision, Determinismus und Nachvollziehbarkeit sorgen. Außerdem verbrauchen sie natürlich um Größenordnungen weniger Ressourcen und sind auch lokal verfügbar. Wem das alles nicht wichtig ist, der kann auch gern zur KI greifen.

 

Mehr zum Thema gibt es beim Software Architecture Forum 2026. In einer Session zeigt Michael Sperber, wie funktionale Architektur dabei hilft, Kopplung zu reduzieren und die Datenmodellierung zu verbessern. In einer weiteren Session demonstriert er, wie domänenspezifische Sprachen Fachlichkeit näher an die Architektur bringen und flexiblere Systeme ermöglichen.

 

Über den Sprecher:

Dr. Michael Sperber ist Geschäftsführer der Active Group GmbH, die Individualsoftware ausschließlich mit funktionaler Programmierung entwickelt. Er ist international anerkannter Experte für funktionale Programmierung und wendet sie seit über 20 Jahren in Forschung, Lehre und industrieller Entwicklung an. Außerdem hat er zahlreiche Fachartikel und Bücher zum Thema verfasst. Michael Sperber ist Mitbegründer des Blogs funktionale-programmierung.de und Mitorganisator der Entwicklerkonferenz BOB.