Connect with us

Entwicklung & Code

Event-Driven, Teil 6: Eine Stadtbibliothek als Event-getriebenes System


Nachdem sich die bisherigen Teile dieser Serie mit den Grundlagen Event-getriebener Architektur beschäftigt haben, soll es nun konkret werden. Anhand eines durchgehenden Beispiels werde ich zeigen, wie sich ein System von Grund auf modellieren lässt – nicht ausgehend von Tabellen, Datenbanken oder APIs, sondern ausgehend von den fachlichen Vorgängen selbst.


the next big thing – Golo Roden

the next big thing – Golo Roden

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.

Dieses Beispiel ist bewusst einfach gehalten, aber dennoch realistisch: eine Stadtbibliothek.

In dieser Bibliothek können Benutzerinnen und Benutzer Bücher ausleihen, verlängern und zurückgeben. Geben sie Bücher zu spät zurück, fallen Mahngebühren an. All diese Vorgänge folgen festen fachlichen Regeln – und genau dort setzt unser Architekturansatz an: Wir fragen nicht zuerst nach Datenstrukturen, sondern nach dem, was passiert.

Damit wird schnell klar, worum es in der Event-getriebenen Architektur geht: um Ereignisse. Statt den aktuellen Zustand zentral zu modellieren, konzentrieren wir uns auf die Vorgänge, die zu diesem Zustand führen. Ein System beschreibt nicht einfach, wie etwas ist, sondern erzählt, was vorgefallen ist.

Bevor überhaupt an eine Implementierung zu denken ist, beginnen wir mit einem Perspektivwechsel: Welche fachlich relevanten Ereignisse treten in der Domäne überhaupt auf?

Für unsere Stadtbibliothek ergeben sich schnell typische Beispiele:

  • „Buch wurde ausgeliehen.“
  • „Buch wurde zurückgegeben.“
  • „Leihfrist wurde verlängert.“
  • „Rückgabe war verspätet.“
  • „Mahngebühr wurde fällig.“
  • „Mahngebühr wurde bezahlt.“

Diese Events beschreiben konkrete Tatsachen – nicht bloße Zustände, sondern Veränderungen. Sie machen sichtbar, was passiert ist, wann es passiert ist und, je nach Eventstruktur, auch warum.

Als Beispiel dient hier ein klassischer Ausleihvorgang. Der Benutzer leiht ein Buch aus – das System erzeugt das Event „Buch wurde ausgeliehen“. Wird das Buch nicht fristgerecht zurückgegeben, stellt das System fest, dass die Rückgabe verspätet ist – „Rückgabe war verspätet“. Als Folge davon wird eine Mahngebühr fällig. Auch das ist ein Event: „Mahngebühr wurde fällig“. Bezahlt der Benutzer diese Gebühr, entsteht das nächste Event – „Mahngebühr wurde bezahlt“. Und schließlich: „Buch wurde zurückgegeben.“

Was auffällt: Es ist nicht notwendig, den Status des Buches zentral zu speichern, sondern der gesamte Ablauf ergibt sich aus der Abfolge der Ereignisse. Der aktuelle Zustand kann jederzeit aus der Historie rekonstruiert werden. Und mehr noch: Die gesamte Geschichte bleibt nachvollziehbar.

Natürlich entstehen Events nicht von selbst. Meistens gehen ihnen sogenannte Commands voraus – also Aufforderungen an das System, etwas zu tun. Wenn eine Benutzerin oder ein Benutzer ein Buch ausleihen möchte, sendet sie oder er ein Command wie „Leihe Buch aus.“ Das System prüft, ob das Command zulässig ist – ist das der Fall, erzeugt es das entsprechende Event: „Buch wurde ausgeliehen.“

Wichtig ist dabei die Trennung: Commands drücken Absichten aus, Events dokumentieren Fakten. Nicht jedes Command führt zu einem Event – wenn die Voraussetzungen nicht erfüllt sind, kann ein Command abgelehnt werden. Diese Trennung hilft dabei, Abläufe präzise zu modellieren und Fachlichkeit sauber umzusetzen.

Aus den gespeicherten Event kann jederzeit der aktuelle Zustand berechnet werden. Dazu dienen sogenannte Projections – lesbare, abfragbare Sichten auf das System. Eine Projection beantwortet Fragen wie: Welche Bücher hat ein Benutzer gerade ausgeliehen? Welche Mahngebühren sind offen? Wann wurde ein bestimmtes Buch zuletzt zurückgegeben?

Diese Projections enthalten keine eigene Logik. Sie basieren ausschließlich auf der Verarbeitung von Events. Ihr großer Vorteil: Sie lassen sich gezielt für bestimmte Anwendungsfälle optimieren, ohne dass dies Auswirkungen auf andere Teile des Systems hätte.

Durch diese Herangehensweise entsteht eine Architektur, die eng an der Fachlichkeit orientiert ist. Statt technischer Artefakte stehen tatsächliche Abläufe im Zentrum. Die Fachsprache wird zum Strukturgeber des Systems. Events dienen dabei nicht nur als interne Verarbeitungsgrundlage, sondern oft auch als Kommunikationsmittel zwischen Komponenten oder Systemen – etwa, indem sie über eine Message Queue veröffentlicht und von anderen Diensten abonniert werden.

Die Vorteile liegen auf der Hand: Systeme werden modularer, verständlicher und besser wartbar. Änderungen sind nachvollzieh- und neue Anforderungen sind oft durch das Hinzufügen neuer Reaktionen auf bestehende Events umsetzbar. Die Trennung von Schreiben und Lesen (Command Query Responsibility Segregation, CQRS) führt zudem zu klareren Verantwortlichkeiten und besserer Skalierbarkeit.

Dieses Beispiel einer Stadtbibliothek zeigt, wie Event-getriebene Architektur in der Praxis gedacht werden kann. Entscheidend ist nicht die konkrete technische Umsetzung, sondern der Perspektivwechsel: Weg vom aktuellen Zustand, hin zur Historie der fachlichen Ereignisse.

Im nächsten und letzten Teil dieser Serie wird es darum gehen, wie man mit Event-getriebener Architektur in einem echten Projekt startet: Welche Rollen beteiligt sind, wie man Events mit Fachleuten entwickelt – und welche Schritte für erste Experimente besonders geeignet sind.


(mai)



Source link

Entwicklung & Code

Spiele-Engine Godot 4.5 bringt Screenreader-Support und Stencil Buffer


Das Godot-Entwicklungsteam hat Version 4.5 der quelloffenen Game-Engine für 2D- und 3D-Spiele veröffentlicht. Das Update ermöglicht Screenreader-Support für Teile des UI-Editors, eine Live-Preview des GUI in mehreren Sprachen und neue optische Spieleeffekte.

Für neue optische Möglichkeiten lassen sich nun Stencil Buffer verwenden: Mit ihnen lässt sich beispielsweise im Spiel ein Loch in eine Wand bohren, um zu sehen, was sich auf der anderen Seite befindet. Stencil Buffer ähneln den bestehenden Depth Buffern, sind jedoch flexibler und bieten mehr Kontrolle. Wie das aussehen kann, demonstriert ein Video in der Ankündigung.


Stencil Buffer in Aktion

Stencil Buffer in Aktion

Stencil Buffer in Aktion

(Bild: godotengine.org)

Der Editor wird in Godot 4.5 barrierefreier: Screenreader können nun mit Control-Nodes umgehen und es sind Screenreader-Bindings vorhanden, um das Verhalten aller Node-Typen anzupassen. Das konnte das Godot-Team mithilfe des AccessKit umsetzen, einer Accessibility-Infrastruktur für UI-Toolkits.

Diese Änderungen sind derzeit als experimentell eingestuft und der Screenreader-Support für den Godot-Editor ist noch nicht vollständig. Er gilt derzeit lediglich für den Project Manager, Standard-UI-Nodes und den Inspector. In künftigen Updates soll die Accessibility weiter verbessert werden.

Auch an der Zugänglichkeit in verschiedenen Sprachen hat das Godot-Team gearbeitet: Das neue Feature „Internationalization Live Preview“ zeigt eine Echtzeitvorschau für Übersetzungen direkt im Editor-Viewport und soll das GUI-Testing in mehreren Sprachen vereinfachen.


Live-Vorschau für Internationalisierung, hier am Beispiel Japanisch

Live-Vorschau für Internationalisierung, hier am Beispiel Japanisch

Live-Vorschau für Internationalisierung, hier am Beispiel Japanisch

(Bild: godotengine.org)

Zudem ist es im Editor nun möglich, die Sprache ohne Neustart zu ändern. Das soll beispielsweise beim Entwickeln von Editor-Plug-ins hilfreich sein, um Übersetzungen zu testen.

Zu den weiteren Neuerungen im Editor zählt unter anderem ein „Mute“-Button. Beim Debuggen kann es vorkommen, dass Entwicklerinnen und Entwickler wieder und wieder die gleiche Spielemusik hören. Um das zu vermeiden, ohne den Ton komplett ausschalten zu müssen, hat das Godot-Team in der Game View eine neue Option eingeführt. Der Ton lässt sich dort nun per Klick auf ein Lautsprecher-Icon ausschalten:


Ein Klick auf "Mute", und schon haben Developer Ruhe beim Debugging.

Ein Klick auf "Mute", und schon haben Developer Ruhe beim Debugging.

Ein Klick auf „Mute“, und schon haben Developer Ruhe beim Debugging.

(Bild: godotengine.org)

Ein anderes Editor-Update betrifft die Ansicht: Auf HiDPI-Bildschirmen konnten die Standard-Steuerelemente und das Editor-UI bisher unscharf aussehen. Auch hier hat das Entwicklungsteam nachgebessert und das Rendering überarbeitet, um die Elemente auf allen Monitoren scharf darzustellen.

Weitere Details zu allen Neuerungen in Version 4.5 präsentiert die detaillierte Ankündigung auf der Godot-Website.


(mai)



Source link

Weiterlesen

Entwicklung & Code

Die Produktwerker: Berufsbild von UX-Professionals


In dieser Folge berichtet Thomas Jackstädt, der Präsident der German UPA – dem Berufsverband für User Experience und Usability Professionals –, über die aktuelle Entwicklung des Berufsbilds von UX-Professionals: als Menschen, die Produkte und Services so gestalten, dass sie nutzbar, verständlich und erlebbar werden. Doch das Bild dieser Rolle ist in Bewegung. Unterschiedliche Titel wie UX-Designer, Service-Designer oder Strategic Designer machen es Teams schwer, den Mehrwert von UX-Professionals eindeutig zu greifen.

Im Gespräch mit Dominique Winter erklärt Jackstädt, dass die German UPA daran arbeitet, Orientierung zu schaffen und das Berufsbild klarer zu definieren. Dabei geht es nicht um starre Festlegungen, sondern um Empfehlungen, die sowohl UX-Professionals selbst als auch Unternehmen, Hochschulen und Weiterbildungsanbieter nutzen können. Klarheit ist für die Zusammenarbeit im Team, für Recruiting und für die Ausgestaltung von Rollenprofilen entscheidend.

Ein (wenig überraschender) Treiber dieser Veränderungen ist die künstliche Intelligenz (KI). Während die Digitalisierung Informationen schnell verfügbar gemacht hat, verändert KI die Art, wie Inhalte und Designs überhaupt entstehen. UX-Professionals müssen lernen, diese Werkzeuge sinnvoll einzusetzen, ihre Qualität einzuschätzen und zu orchestrieren. So können sie den Freiraum nutzen, sich stärker auf die menschliche Erfahrung im Nutzungskontext zu konzentrieren.

Gleichzeitig bleibt die Unterscheidung zwischen Professionalität und Amateurarbeit wichtig. Professionalität bedeutet nicht automatisch bessere Ergebnisse, aber sie steht für Verlässlichkeit, methodisches Vorgehen und Orientierung an den Bedürfnissen der Nutzenden. UX-Professionals stellen sicher, dass Lösungen nicht irritieren, sondern verständlich sind und echten Mehrwert bringen.

Für Produktteams bedeutet diese Entwicklung, dass die Zusammenarbeit mit UX-Professionals an Bedeutung gewinnt. Product Owner, Product Manager oder Product Leads profitieren von Rollen, die Klarheit in der Gestaltung schaffen, auch wenn KI immer mehr Aufgaben übernimmt. Statt Spezialisierungen aufzulösen, entsteht ein neues Zusammenspiel von Generalisten, Tools und spezifischem Fachwissen. Entscheidend bleibt, dass Produkte menschenzentriert gestaltet werden; egal, wie stark Maschinen an ihrer Entstehung beteiligt sind.


Product Owner Day 2025, Online-Konferenz

Product Owner Day 2025, Online-Konferenz

(Bild: deagreez/123rf.com)

So geht Produktmanagement: Auf der Online-Konferenz Product Owner Day von dpunkt.verlag und iX am 13. November 2025 können Product Owner, Produktmanagerinnen und Service Request Manager ihren Methodenkoffer erweitern, sich vernetzen und von den Good Practices anderer Unternehmen inspirieren lassen.

Thomas Jackstädt denkt, dass UX-Professionals sich zu „KI-Natives“ entwickeln müssen, ohne ihren Kernauftrag zu verlieren: für Menschen zu gestalten. Die Rolle verändert sich, bleibt aber essenziell für den Erfolg von Produkten. Denn am Ende zählt nicht, wie schnell etwas produziert werden kann, sondern ob es verständlich, zugänglich und nützlich ist.

Die aktuelle Ausgabe des Podcasts steht auch im Blog der Produktwerker bereit: „Berufsbild von UX-Professionals„.


(mai)



Source link

Weiterlesen

Entwicklung & Code

KI-Überblick 5: Transformer – Self-Attention verändert die Sprachverarbeitung


Lange galten Recurrent Neural Networks (RNNs) als der Goldstandard für das Verarbeiten von Sprache. Sie waren dafür gemacht, Sequenzen schrittweise zu verarbeiten und dabei frühere Informationen im Gedächtnis zu behalten. Doch sie hatten Grenzen – insbesondere bei langen Texten, komplexen Abhängigkeiten und paralleler Verarbeitung.


the next big thing – Golo Roden

the next big thing – Golo Roden

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.

Mit dem Aufkommen der Transformer-Architektur hat sich das grundlegend geändert. Sie hat sich nicht nur als leistungsfähiger erwiesen, sondern auch als effizienter, skalierbarer und flexibler. Inzwischen ist sie die dominierende Grundlage für viele KI-Systeme, darunter BERT, GPT, T5 und viele mehr.

In diesem Beitrag zeige ich Ihnen, was Transformer-Modelle auszeichnet, warum Self-Attention der entscheidende Mechanismus ist und wie diese Architektur das maschinelle Lernen verändert hat.

Recurrent Neural Networks verarbeiten Texte sequenziell – Wort für Wort oder Zeichen für Zeichen. Dabei führen sie ein internes Gedächtnis mit, das bei jedem Schritt aktualisiert wird. Dieses Prinzip funktioniert gut für kurze Eingaben, stößt jedoch bei längeren Sequenzen an mehrere Grenzen:

  • Langfristige Abhängigkeiten gehen verloren: Frühere Informationen verblassen über die Zeit.
  • Keine echte Parallelisierung möglich: Da jedes Wort auf dem vorherigen basiert, kann nicht gleichzeitig verarbeitet werden.
  • Begrenzter Zugriff auf den Kontext: Jedes Element sieht nur den bisherigen Verlauf, nicht den gesamten Zusammenhang.

Diese strukturellen Schwächen führten dazu, dass selbst mit Verbesserungen wie LSTM oder GRU viele Sprachaufgaben schwer zu lösen blieben.

Die Transformer-Architektur wurde 2017 in dem Paper „Attention Is All You Need“ vorgestellt. Der zentrale Gedanke: Statt Informationen sequenziell zu verarbeiten, sollen alle Teile eines Textes gleichzeitig betrachtet werden – mithilfe eines Mechanismus namens „Self-Attention“.

Transformer-Modelle bestehen nicht mehr aus rekursiven Schleifen, sondern aus einem Stapel gleichartiger Schichten, die Eingaben parallel verarbeiten. Jede Schicht analysiert dabei, welche Teile der Eingabe wie stark miteinander in Beziehung stehen – unabhängig von der Position.

Dieses Prinzip erlaubt es dem Modell:

  • Kontext über beliebige Distanzen hinweg zu berücksichtigen,
  • Ein- und Ausgaben gleichzeitig zu verarbeiten und
  • die gesamte Eingabe als Ganzes zu analysieren.

Der Self-Attention-Mechanismus bewertet für jedes Element in einer Eingabesequenz, wie stark es auf alle anderen Elemente achten sollte. Vereinfacht gesagt:

  • Jedes Wort erzeugt eine gewichtete Kombination aller anderen Wörter.
  • Diese Gewichtung ergibt sich aus der inhaltlichen Ähnlichkeit.
  • So kann zum Beispiel das Wort „sie“ korrekt auf „die Frau“ zurückverweisen, auch wenn diese am Satzanfang steht.

Mathematisch geschieht das über sogenannte Query-, Key– und Value-Vektoren, die aus den Eingabedaten erzeugt werden. Diese werden paarweise miteinander kombiniert, um zu bestimmen, wie viel Aufmerksamkeit jedes Token auf andere richten soll. Die resultierenden Gewichte fließen dann in die nächste Repräsentation ein.

Der Effekt: Das Modell kann flexibel entscheiden, welche Informationen an welcher Stelle wichtig sind – unabhängig von der linearen Reihenfolge.

Da Transformer-Modelle die Reihenfolge der Eingaben ignorieren können, benötigen sie eine zusätzliche Komponente, nämlich die positionale Kodierung. Sie sorgt dafür, dass die relative und absolute Position von Wörtern im Satz erhalten bleibt. Ohne diesen Schritt wäre ein Satz wie „Die Katze jagt die Maus“ nicht von „Die Maus jagt die Katze“ zu unterscheiden.

Die Positionsinformation wird meist als Vektor addiert oder eingebettet und fließt gemeinsam mit dem Inhalt in die Berechnung der Aufmerksamkeit ein.

Ein vollständiger Transformer besteht typischerweise aus mehreren aufeinanderfolgenden Encoder- und/oder Decoder-Schichten, je nach Anwendungsfall:

  • Encoder-only-Modelle (zum Beispiel BERT) analysieren Texte, etwa für Klassifikation oder Fragebeantwortung.
  • Decoder-only-Modelle (zum Beispiel GPT) erzeugen Texte, etwa beim Autovervollständigen.
  • Encoder-Decoder-Modelle (zum Beispiel T5) übersetzen oder transformieren Texte zwischen Formaten.

Die Fähigkeit, diese Architekturen effizient auf große Datenmengen und Modellgrößen zu skalieren, hat den Siegeszug der Transformer entscheidend geprägt. Moderne Modelle enthalten Milliarden von Parametern und lernen auf Datenmengen, die frühere Verfahren unvorstellbar überfordert hätten.

Transformer-Modelle verdanken ihren Erfolg mehreren Faktoren:

  • Sie verarbeiten Sprache kontextsensitiv und global, nicht lokal und sequenziell.
  • Sie lassen sich hochgradig parallelisieren, was das Training beschleunigt.
  • Sie sind modular und lassen sich flexibel für unterschiedliche Aufgaben anpassen.
  • Sie eignen sich nicht nur für Sprache, sondern auch für Bilder, Videos, Molekülstrukturen und vieles mehr.

Dadurch haben sie sich zum universellen Baukasten moderner KI entwickelt.

Der nächste Teil befasst sich mit Large Language Models wie GPT, BERT oder Claude. Er wird zeigen, was diese Modelle von klassischen Sprachverarbeitungsansätzen unterscheidet, wie sie trainiert werden und warum sie so viele Aufgaben scheinbar mühelos lösen – obwohl sie kein echtes Verständnis besitzen.


(rme)



Source link

Weiterlesen

Beliebt