Die meisten heute eingesetzten Softwaresysteme folgen klassischen Architekturmustern: Sie basieren auf einem relationalen Datenmodell, nutzen eine Schichtenarchitektur und stellen ihre Funktionen über eine REST-API oder eine Weboberfläche zur Verfügung. Dieses Vorgehen ist weit verbreitet, gut dokumentiert und in vielen Fällen auch ausreichend – zumindest auf den ersten Blick.
Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.
Doch mit zunehmender Komplexität treten wiederkehrende Probleme auf. Die Anwendungen werden schwer verständlich. Änderungen sind riskant. Die ursprüngliche Fachlichkeit ist im Code kaum noch zu erkennen. Warum ist das so?
Die Illusion einfacher Architektur
Das klassische CRUD-Modell (Create, Read, Update, Delete) ist intuitiv und direkt. Es orientiert sich an Tabellen und erlaubt einfache Operationen auf Daten. In kleinen Systemen oder Admin-Oberflächen ist das oft völlig ausreichend.
Doch sobald Anwendungen eine gewisse Komplexität erreichen – zum Beispiel durch Regeln, Zustandsübergänge oder Abläufe mit Nebenwirkungen –, stößt das Modell an Grenzen. CRUD speichert nur, was geändert wurde – nicht warum. Es macht keine Aussagen darüber, was passiert ist, sondern lediglich, wie der neue Zustand aussieht.
Und das ist ein Problem: Denn sobald Fachlichkeit nicht mehr direkt sichtbar ist, wird das System intransparent. Der Code beschreibt dann nicht mehr die Abläufe, sondern nur noch die Daten, die dabei herauskommen. Das führt dazu, dass die fachliche Bedeutung verloren geht.
Symptome einer überforderten Architektur
Wenn Architekturen die Fachlichkeit nicht abbilden, zeigt sich das in der Praxis sehr schnell:
- Die Systeme werden schwer verständlich – selbst für die, die sie entwickelt haben.
- Änderungen sind riskant, weil niemand sicher sagen kann, welche Auswirkungen sie haben.
- Workarounds häufen sich, weil sich neue Anforderungen nur schwer in das bestehende Modell integrieren lassen.
- Die Anwendung wird über die Zeit hinweg langsamer, fehleranfälliger und unflexibler.
Hinzu kommt: Klassische REST-APIs und synchroner Datenaustausch zwischen Systemen führen zu starker Kopplung. Systeme warten aufeinander. Fehler propagieren sich. Es entstehen fragile Ketten aus Aufrufen und Abhängigkeiten.
Wo der Denkfehler liegt
Der zentrale Denkfehler liegt in der Reihenfolge: Viele Architekturen beginnen beim Datenmodell. Es wird überlegt, welche Tabellen oder Dokumente gebraucht werden – und erst dann wird über Abläufe und Fachlogik nachgedacht.
Doch Fachlichkeit entsteht nicht aus Daten. Sie entsteht aus Vorgängen. Aus dem, was Menschen tun – aus Abläufen, Entscheidungen und Zustandsübergängen. Erst daraus ergeben sich die Daten.
Wenn man Fachlichkeit durch die Brille des Datenmodells betrachtet, zwingt man sie in ein statisches Schema. Das mag zu Beginn funktionieren, führt aber mittelfristig zu unflexiblen Systemen – weil das Modell sich nicht mehr natürlich mitentwickeln kann.
Ein besserer Ausgangspunkt
Statt mit Tabellen und APIs zu beginnen, sollte man bei den fachlichen Abläufen ansetzen: Was passiert in der Domäne? Welche Vorgänge treten auf? Welche Entscheidungen werden getroffen? Welche Konsequenzen hat das?
Diese Denkweise ist der Kern von Event-getriebener Architektur (Event-Driven Architecture, kurz EDA): Nicht Daten stehen im Zentrum, sondern Ereignisse. Dinge, die passiert sind. Dinge, die eine Bedeutung haben. Und Dinge, auf die andere reagieren können.
Das führt zu einer ganz anderen Struktur von Systemen: Sie werden modularer, entkoppelt, nachvollziehbar – und orientieren sich an dem, was das System eigentlich tun soll.
Was kommt als Nächstes?
Im nächsten Teil dieser Serie schauen wir uns die Bausteine einer Event-getriebenen Architektur genauer an: Commands, Events, Projections, Event-Streams und mehr. Damit wird sichtbar, wie aus fachlichen Vorgängen technische Strukturen entstehen – und wie daraus robuste, verständliche Systeme werden.
(Bild: iX)
Im Sonderheft iX Developer Praxis Softwarearchitektur gibt es neben den klassischen Architekturinhalten zu Methoden und Pattern Artikel über Soziotechnische Systeme, Qualitätssicherung oder Architektur und Gesellschaft. Domain Driven Design ist ebenso ein Thema wie Team Topologies, KI und Sicherheit. Als Autoren konnte die Redaktion bekannte Expertinnen und Experten gewinnen, die ihr Wissen in vielen spannenden Artikeln sowohl für Architektureinsteiger als auch Spezialisten weitergeben.
Das Sonderheft lässt sich im heise shop erwerben.
(mai)
English (US) ·