Event-getriebene Architektur (Event-Driven Architecture, kurz EDA) ist in den letzten Jahren zu einem beliebten Schlagwort geworden. Viele Systeme bezeichnen sich als eventbasiert – oft aber, ohne wirklich das zu tun, was EDA ausmacht.

In diesem Teil der Serie wollen wir klären, was Event-getriebene Architektur wirklich ist – und welche Missverständnisse häufig auftreten.

Was EDA nicht ist

Bevor wir definieren, was EDA bedeutet, ist es hilfreich zu klären, was es nicht ist.

Erstens: Pub/Sub ist keine Event-getriebene Architektur. Viele Systeme arbeiten mit sogenannten Topics, Queues oder Bussen: Ein Service veröffentlicht Nachrichten, ein anderer konsumiert sie. Das ist technisch gesehen Pub/Sub – ein Nachrichtenmuster.

Aber: Das allein macht noch keine Event-getriebene Architektur. Oft werden hier Nachrichten verschickt, die nichts mit Events im eigentlichen Sinne zu tun haben – etwa „setze Preis auf EUR 9,99“ oder „aktualisiere den Bestand“.

Solche Nachrichten beschreiben keine Tatsachen, sondern Anweisungen – sie sind also eher Commands.

Event-Carried State Transfer

Manche Systeme versenden ganze Datenobjekte über Events: „Produkt wurde geändert“ oder „Bestellung wurde aktualisiert“, oft inklusive vollständiger Kopie des aktuellen Zustands. Das nennt man „Event-Carried State Transfer“.

Auch hier ist das Wort „Event“ im Spiel – aber es handelt sich nicht um eine dokumentierte, interpretierbare Historie. Es ist ein Transportmechanismus, nicht mehr. EDA hingegen geht von fachlichen Ereignissen aus – nicht von Datenzuständen.

EDA ist keine Technik, sondern ein Denkmodell

Oft wird EDA mit bestimmten Tools oder Technologien assoziiert: Kafka, EventBridge, RabbitMQ und so weiter. Aber diese Tools sind nicht EDA – sie ermöglichen sie vielleicht, aber sie sind es nicht.

Event-getriebene Architektur ist zuerst ein Denkmodell: Es geht darum, Systeme so zu gestalten, dass sie sich an dem orientieren, was in der Fachlichkeit geschieht – an den Ereignissen.

Was EDA ist

Eine Event-getriebene Architektur orientiert sich an folgenden Prinzipien:

• Fachliche Ereignisse stehen im Mittelpunkt. Das System dokumentiert, was passiert ist – nicht nur, wie der aktuelle Zustand aussieht.
• Abläufe entstehen durch Reaktion auf Events. Systeme reagieren auf Ereignisse – synchron oder asynchron – und leiten daraus neue Aktionen oder Entscheidungen ab.
• Prozesse sind lose gekoppelt. Einzelne Komponenten wissen wenig voneinander – sie tauschen keine direkten Aufrufe aus, sondern reagieren auf gemeinsam verstandene Ereignisse.
• Die Architektur bildet die Fachlichkeit ab. Die Struktur des Codes, der Kommunikation und der Abläufe folgt dem, was im Unternehmen oder der Domäne tatsächlich geschieht.

Und was ist dann CQRS?

CQRS (Command Query Responsibility Segregation) ist ein Architekturprinzip, das häufig im Kontext von EDA auftaucht. Es bedeutet: Schreib- und Lesezugriffe werden getrennt behandelt. Änderungen erfolgen über Commands, Lesefunktionen greifen auf optimierte Projektionen zu.

CQRS ist kein Muss für EDA – aber es passt sehr gut dazu, weil es viele Herausforderungen elegant löst:

• Commands führen zu Events.
• Events aktualisieren Projections.
• Queries lesen ausschließlich aus Projections.

Das Ergebnis ist ein System mit klaren Verantwortlichkeiten, entkoppelten Prozessen und hoher Nachvollziehbarkeit.

Was kommt als Nächstes?

Der nächste Teil wird zeigen, welche Eigenschaften gute Events ausmachen – und welche typischen Fallstricke man vermeiden sollte, wenn man mit Event-getriebener Architektur arbeitet.

(mai)

Digitale Barrierefreiheit baut auf vier Grundprinzipien auf, die sich auf die Gestaltung von Produkten, Dienstleistungen, Inhalten und Umgebungen beziehen. Diese Grundprinzipien sollen sicherstellen, dass digitale Inhalte für alle Nutzenden, unabhängig von ihren Fähigkeiten, zugänglich sind. Das erlaubt eine möglichst vollständige digitale Erfahrung für alle. Dieser zweite Teil der Artikelserie erläutert die Prinzipien, stellt hilfreiche Tools vor und gibt Tipps zum Überprüfen und Implementieren.

Tabelle: Grundprinzipien der digitalen Barrierefreiheit

Wahrnehmbarkeit

Nicht alle Menschen können gut sehen und hören. Deshalb müssen alle inhaltlichen Informationen einer Internetseite und alle Komponenten einer Benutzeroberfläche für alle Nutzenden in einer für sie wahrnehmbaren Weise dargestellt werden.

Stellen Sie sich beispielsweise Lisa Beer vor. Sie arbeitet als Bürokauffrau und hat eine starke Sehbeeinträchtigung. Lisa soll eine aktuelle Übersicht über alle derzeit verfügbaren digitalen Telefonanlagen erstellen. Viele der relevanten Seiten im Internet enthalten Bild- und Videoinformationen, die sie aufgrund ihrer Sehbeeinträchtigung nicht wahrnehmen kann. Wenn für diese visuellen Inhalte Textalternativen, Untertitel und Audiobeschreibungen existieren, kann Lisa ebenso wie ihre Kolleginnen und Kollegen selbständig und ohne Probleme die Übersicht zusammenstellen.

Um das Grundprinzip der Wahrnehmbarkeit umzusetzen, sollten Webentwicklerinnen und -entwickler die folgenden Kriterien berücksichtigen (siehe W3C – Perceivable information and user interface):

• Erstellen von Alternativtexten für Bilder, Icons, Schaltflächen und Grafiken
• Beschreibung von Daten in Tabellen, Diagrammen und Illustrationen
• Beschriftungen für Formularsteuerungen, Eingaben und andere Komponenten der Useroberfläche
• Vermeiden von Schriftgrafiken
• Transkripte und Untertitel für Audioinhalte
• Audiodeskriptionen (Beschreibung wichtiger visueller Details in einem Video)
• Gebärdensprachvideos für Audioinhalte
• Ausreichender Kontrast zwischen Vorder- und Hintergrundfarbe
• Farbe nicht als einziges unterscheidendes Merkmal für die Identifikation von Inhalten und Navigationselementen
• Textvergrößerung auf bis zu mindestens 200 Prozent möglich, ohne dass sich Informationen überlappen oder verloren gehen
• Audiowiedergaben lassen sich stoppen, neu starten oder beenden
• Hintergrundtöne lassen sich anpassen oder abschalten

Bedienbarkeit

Viele Menschen können aus unterschiedlichen Gründen keine Computermaus nutzen und verwenden für das Surfen im Internet die Tastatur oder alternative Eingabemöglichkeiten. Deshalb sollten alle Inhalte, alle Komponenten der Useroberfläche und Navigationselemente über verschiedene Methoden erreichbar und bedienbar sein, etwa über die Tastatur, durch Berührung und Gesten oder durch Sprachbefehle. Dies ermöglicht es Nutzenden mit verschiedenen Beeinträchtigungen, wie motorischen Einschränkungen, digitale Inhalte zu erreichen und mit ihnen zu interagieren.

Das folgende Beispiel zeigt die Relevanz dieses Grundprinzips: Fred Maier hat bei einem Verkehrsunfall den rechten Arm verloren. Er arbeitet als Redakteur in einem Online-Verlag und nutzt eine Einhandtastatur ohne integrierte Maus. Die Tastatur bedient er mit der linken Hand. Damit er seine Recherchen ohne fremde Hilfe ausführen kann, müssen die Webseiten, die er besucht, vollständig über die Tastatur bedienbar sein. Dafür müssen die folgenden Kriterien erfüllt sein:

• Verfügbarkeit aller Funktionen, die mit der Maus ansteuerbar sind, auch über die Tastatur
• Durchgehender Tastaturfokus, Fokus bleibt nicht an einem Teil des Inhalts hängen
• Webbrowser, Authoring-Tools und andere Tools bieten Tastaturunterstützung

Zur Bedienbarkeit gehören aber noch weitere Aspekte, die über den nahtlosen Einsatz der Tastatur hinausgehen. Manche Menschen brauchen beispielsweise mehr Zeit als andere, um digitale Inhalte zu lesen und zu nutzen, Text zu tippen, Anweisungen zu verstehen, Bedienelemente zu betätigen oder andere Aufgaben auf einer Webseite zu erledigen. Dafür müssen die folgenden Kriterien berücksichtigt werden:

• Möglichkeit, Zeitlimits anzuhalten, zu verlängern oder anzupassen
• Anhalten, Stoppen oder Ausblenden von sich bewegenden, blinkenden oder scrollenden Inhalten
• Möglichkeit, Unterbrechungen zu verschieben oder zu unterdrücken
• Möglichkeit zur Neuauthentifizierung, wenn eine Sitzung abläuft, ohne Daten zu verlieren

Inhalte, die in bestimmten Raten oder Mustern blinken, können bei den Nutzenden lichtempfindliche Reaktionen oder Krampfanfälle auslösen. Idealerweise vermeiden Entwicklerinnen und Entwickler blinkende Inhalte ganz oder verwenden sie nur in einer Weise, die keine bekannten Risiken birgt. Auch Animationen und bewegte Inhalte können Unbehagen und Stress verursachen oder körperliche Reaktionen hervorrufen.

Gut strukturierte Inhalte helfen den Nutzenden einer Website, sich zu orientieren und effektiv zu navigieren. Auf jeder einzelnen Webseite einer gut designten Website müssen die folgenden Kriterien umgesetzt sein:

• Eindeutige Titel und beschreibende Abschnittsüberschriften auf allen Seiten
• Implementierung verschiedener Suchstrategien
• Erkennbare Markierung des aktuellen Standorts innerhalb einer Reihe von zusammenhängenden Seiten
• Möglichkeit, sich wiederholende Inhaltsblöcke zu umgehen
• Gut erkennbarer Tastaturfokus und sinnvolle Reihenfolge
• Zweck eines Links ist erkennbar und verständlich

All das hilft dabei, auf unterschiedliche Weise durch Webseiten zu navigieren. Während einige Menschen beispielsweise hierarchische Navigationsstrukturen wie Menüleisten bevorzugen, um bestimmte Webseiten zu finden, nutzen andere stattdessen die Suchfunktionen auf Webseiten. Manche Nutzende sehen die Inhalte, andere hören sie oder sehen und hören sie gleichzeitig. Einige Menschen nutzen die Inhalte nur mit der Maus oder der Tastatur, während andere beides benutzen.

Touchscreens und mobile Endgeräte mit alternativen Eingabemodalitäten, wie Berührungsaktivierung, Spracheingabe und Gesten, erleichtern es vielen Menschen mit Beeinträchtigungen, digitale Inhalte und Dienste zu nutzen. Zusätzliche Designüberlegungen maximieren den Nutzen dieser Möglichkeiten. Dazu gehören:

• Alternativen für Gesten, die Geschicklichkeit oder feine Bewegungen erfordern
• Vermeidung von versehentlicher Aktivierung von Komponenten durch eindeutige Gestaltung, etwa durch eine Rückgängig-Funktion
• Verwendung von Bezeichnungen, die dem Objektnamen im Code entsprechen, um die Aktivierung durch Sprache zu unterstützen
• Alternative Bedienung von Funktionen, die durch Bewegung aktiviert werden können
• Ausreichende Größe von Schaltflächen, Links und aktiven Komponenten, um sie leicht durch Berührung aktivieren zu können

Verständlichkeit

Die Verständlichkeit einer Webseite ist dann gegeben, wenn die auf den Seiten verfügbaren Inhalte gut lesbar und verständlich sowie die Struktur und die Organisation nachvollziehbar sind und alle Bedienelemente erwartbar und nachvollziehbar funktionieren. Zusätzlich sollten alternative Ein- und Ausgabemöglichkeiten vorhanden sein, die helfen, Bedienfehler zu vermeiden und den Nutzenden bei der Verbesserung von Fehlern helfen.

Hier soll ein Beispiel einer Person mit einer Lernbeeinträchtigung zur Verdeutlichung dienen: Thomas Werner hat eine Lernbeeinträchtigung und arbeitet in einer Werkstatt für Menschen mit Behinderungen (WfbM). Er engagiert sich im Werkstattrat und informiert sich regelmäßig über aktuelle sozialpolitische Entwicklungen. Dafür besucht er oft Webseiten der Bundes- und Landesministerien. Dort findet er zu vielen Themen Informationen in Leichter Sprache, die ihm helfen, Inhalte und Zusammenhänge besser zu verstehen.

Um eine gute Verständlichkeit zu ermöglichen, sollten Entwicklerinnen und Entwickler die folgenden Kriterien umsetzen:

• Angabe der Hauptsprache einer Webseite (für die passende Spracheinstellung des Screenreaders)
• Angabe von Änderungen der Sprache in Textpassagen, Phrasen oder einzelnen Teilen einer Webseite
• Bereitstellen von Definitionen für ungewöhnliche Wörter, Sätze, Redewendungen und Abkürzungen
• Verwenden von möglichst klarer und einfacher Sprache oder Bereitstellen von Inhalten in Leichter Sprache
• Gleiche Positionierung von Navigationselementen, die auf mehreren Seiten wiederholt werden
• Gleiche Bezeichnungen für Komponenten der Benutzeroberfläche, die sich auf mehreren Seiten wiederholen
• Keine signifikanten Änderungen auf einer Webseite ohne die Zustimmung der Nutzenden, beispielsweise Änderung von Berechtigungen

Das Ausfüllen von Formularen und andere Interaktionen können für manche Menschen schwierig sein und vermehrt Fehler erzeugen. Ein sinnvolles Design kann beim Verständnis der Struktur und der Korrektur von Fehlern unterstützen:

• Bereitstellen von beschreibenden Anweisungen, Fehlermeldungen und Vorschlägen zur Korrektur
• Kontextsensitive Hilfe für komplexere Funktionen und Interaktionen
• Möglichkeit, Eingaben zu überprüfen, zu korrigieren oder rückgängig zu machen

Robustheit

Das vierte und letzte Prinzip der barrierefreien Webentwicklung ist die Robustheit. Das bedeutet in diesem Fall, dass alle Inhalte und Steuerelemente mit aktuellen und zukünftig genutzten Werkzeugen und Infrastrukturelementen kompatibel sind. Dazu gehören die verschiedenen Browser und Betriebssysteme sowie assistive Technologien und andere Nutzeragenten (User Agents).

Ein weiteres Beispiel verdeutlicht die Relevanz: Anna Berger ist blind und nutzt für ihre Arbeit als Übersetzerin einen Screenreader. Damit dieser alle textuellen Informationen korrekt vorlesen kann, muss das auf der Seite verwendete Markup standardkonform sein. Da sie viele ausländische Seiten besucht, ist es wichtig, dass der Screenreader Informationen über die verwendete Sprache erhält, damit die Inhalte in der entsprechenden Sprache vorgelesen werden können. Um immer mit der aktuellen Version der Screenreader-Software arbeiten zu können, macht Anna Berger regelmäßige Updates. Mit einer standardkonformen Verwendung von Markups können Entwicklerinnen und Entwickler sicherstellen, dass der Screenreader auch nach den Updates fehlerfrei funktioniert.

Das Umsetzen folgender Kriterien verbessert die Robustheit von Webseiten:

• Sicherstellen, dass verwendete Markups durch standardkonforme Anwendung zuverlässig interpretierbar sind
• Bereitstellen eines Namens, einer Rolle und eines Wertes für nicht standardisierte Komponenten der Useroberfläche
• Statusmeldungen, die Nutzenden von assistiven Technologien präsentiert werden können, ohne Fokus zu erhalten

Damit steigt die Kompatibilität mit aktuellen und zukünftigen Nutzeragenten, einschließlich unterstützender Technologien, und assistive Technologien können die Inhalte der Seiten zuverlässig verarbeiten und adäquat darstellen, auch bei nicht standardisierten Schaltflächen, Eingabefeldern und anderen Steuerelementen.

Das quelloffene Webframework Nuxt.js hat sein viertes Major Release erreicht, das insbesondere auf Stabilität ausgelegt ist und Breaking Changes zur Verbesserung der Developer Experience enthält. Version 4.0 führt unter anderem eine neue Organisationsstruktur für Projekte ein, aktualisiert das Data Fetching, kann besser mit der Programmiersprache TypeScript umgehen und beschleunigt das Command-Line Interface (CLI).

Bei Nuxt.js handelt es sich um ein Framework zum Entwickeln grafischer Oberflächen für Webanwendungen. Es setzt auf dem JavaScript-Framework Vue.js auf und macht sich dessen reaktive, komponentenbasierte Architektur zunutze. Daneben verwendet Nuxt.js den Bundler Vite und die Server Engine Nitro.

Saubere Projektstruktur mit app/-Verzeichnis

Nuxt.js 4.0 bringt das neue Verzeichnis app/ mit, das für eine sauberere Projektorganisation sorgen soll. Im Standard befindet sich Anwendungscode nun unter app/. Das soll dabei helfen, den Code von node_modules/ und .git/ getrennt zu halten und somit File Watchers insbesondere unter Windows und Linux zu beschleunigen. Zudem sollen Entwicklungsumgebungen durch die neue Struktur besser den Kontext erkennen können, ob gerade am Client- oder Server-Code gearbeitet wird.

my-nuxt-app/
├─ app/
│  ├─ assets/
│  ├─ components/
│  ├─ composables/
│  ├─ layouts/
│  ├─ middleware/
│  ├─ pages/
│  ├─ plugins/
│  ├─ utils/
│  ├─ app.vue
│  ├─ app.config.ts
│  └─ error.vue
├─ content/
├─ public/
├─ shared/
├─ server/
└─ nuxt.config.ts

Entwicklerinnen und Entwickler, die nicht zur neuen Struktur migrieren möchten, müssen dies nicht tun, denn Nuxt.js erkennt bestehende Strukturen und behält diese bei.

Verbesserter TypeScript-Support und CLI-Beschleunigung

Im neuen Release erstellt Nuxt.js separate TypeScript-Projekte für App-Code, Server-Code, den shared/-Ordner und Builder-Code. Das soll zu einer verbesserten Autovervollständigung, akkuraterer Typinferenz und weniger verwirrenden Fehlermeldungen beim Arbeiten in unterschiedlichen Kontexten führen.

Zudem hat das Nuxt.js-Team das CLI (@nuxt/cli) beschleunigt. Zu den neuen Änderungen zählt, dass Cold Starts nun deutlich schneller vonstatten gehen und der Node.js-Compile-Cache den V8-Compile-Cache wiederverwendet.

Upgrade auf die neue Hauptversion

Wie das Nuxt.js-Team betont, bringt zwar jede Hauptversion abwärtsinkompatible Neuerungen (Breaking Changes) mit, doch der Upgrade-Prozess auf Version 4.0 solle möglichst glatt funktionieren. Die meisten dieser Änderungen haben demnach bereits über ein Jahr lang per Compatibility Flag zum Testen bereitgestanden. Die meisten lassen sich per Konfigurationsoption zum alten Verhalten zurückdrehen.

Über alle Neuerungen der vierten Hauptversion, die nach einem Jahr des Real-World-Testens erschienen ist, informiert das Entwicklungsteam auf dem Nuxt.js-Blog.

(mai)