Connect with us

Entwicklung & Code

Event-Driven, Teil 2: Die Bausteine von Event-getriebener Architektur


Der erste Teil dieser Serie hat gezeigt, warum klassische Architekturen wie CRUD oder REST an ihre Grenzen stoßen – vor allem, wenn die Fachlichkeit komplexer wird. Doch was ist die Alternative?


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.

Event-getriebene Architekturen (Event-Driven Architecture, kurz EDA) orientieren sich nicht am Datenmodell, sondern an den Vorgängen in der Domäne. Sie setzen auf ein anderes Vokabular, andere Bausteine – und führen zu einem völlig anderen Systemaufbau. Dieser Teil betrachtet die wichtigsten Elemente im Überblick.

Commands: Anweisungen an das System

Ein Command ist eine Aufforderung, etwas zu tun. Es ist ein gerichteter, imperativer Aufruf wie beispielsweise „Verleihe dieses Buch“, „Melde diese Adresse um“ oder „Überweise diesen Betrag“. Commands kommen fast immer von außen, etwa aus einer Benutzeroberfläche, einem anderen System oder einem automatisierten Prozess.

Wichtig ist dabei zu beachten, dass ein Command an sich noch keine Garantie dafür ist, dass etwas geschieht – sondern nur der Versuch, etwas auszulösen. Ob ein Command gültig ist, entscheidet die Domäne: Das System prüft, ob das Command erlaubt ist und ob die fachlichen Bedingungen erfüllt sind.

Events: Was passiert ist

Events sind die Folge von Commands. Sie entstehen als Konsequenz aus den fachlichen Entscheidungen, die beim Verarbeiten des Commands getroffen wurden.

Ein Event beschreibt daher eine fachlich relevante Tatsache, die in der Vergangenheit liegt. Es ist nicht „Bitte mache X“, sondern „X ist geschehen“. Events sind neutral, beschreibend und oft dauerhaft gespeichert. Sie bilden die zentrale Informationsquelle im System.

Passende Beispiele (zu den zuvor genannten Commands) könnten sein: „Buch wurde verliehen“, „Adresse wurde umgemeldet“ oder „Betrag wurde überwiesen“.

Events sind nicht nur nützlich für das System selbst, sondern auch für andere Beteiligte: Sie können andere Prozesse anstoßen, Systeme informieren oder Änderungen in Datenprojektionen auslösen.

Event Streams: Die Geschichte einzelner Objekte

Ein Event Stream ist die zeitlich geordnete Liste aller Events zu einem bestimmten Kontext – etwa zu einer Benutzerin oder einem Benutzer, einem Konto oder einem Buch. Er enthält nur die Ereignisse, die für genau dieses Objekt relevant sind.

Aus einem solchen Stream lässt sich jederzeit der aktuelle Zustand eines Objekts rekonstruieren. Das macht Systeme sehr transparent und nachvollziehbar: Man sieht nicht nur den Status quo, sondern auch, wie es im Laufe der Zeit dazu kam.

Projections: Leseseiten des Systems

Projections dienen schließlich der dauerhaften Abbildung des aktuellen Zustands – sie beantworten Fragen wie: „Wer hat welches Buch ausgeliehen?“, „Wie hoch ist das aktuelle Guthaben?“ oder „Was ist der letzte bekannte Wohnsitz?“.

Sie basieren ausschließlich auf den Events: Aus der Historie dessen, was geschehen ist, wird der aktuelle Zustand berechnet. Dabei kann es viele verschiedene Projektionen gleichzeitig geben – je nachdem, welche Sichten gebraucht werden.

Projections sind oft speziell auf einzelne Anwendungsfälle zugeschnitten und können effizient für Lesezugriffe optimiert werden, unabhängig von der Schreiblogik.

Wie diese Bausteine zusammenspielen

Ein typischer Ablauf in einem Event-basierten System sieht dann wie folgt aus:

  • Eine Anwenderin oder ein Anwender löst ein Command aus (zum Beispiel über eine Interaktion im UI).
  • Das System prüft, ob das Command zulässig ist.
  • Ist er zulässig, werden ein oder mehrere Events erzeugt und gespeichert.
  • Diese Events fließen in Event Streams, aktualisieren Projections, werden gegebenenfalls über Message Queues veröffentlicht und von anderen Systemen konsumiert.

Im Ergebnis erhält man eine klare Trennung von der ursprünglichen Intention (Command) und dem anschließenden Ergebnis (Event), eine transparente Dokumentation der Vorgänge und ein System, das sowohl intern als auch extern nachvollziehbar bleibt.

Was kommt als Nächstes?

Im nächsten Teil wird es darum gehen, was ein Event aus fachlicher Sicht überhaupt ist – und warum es so wichtig ist, sich dabei nicht von technischen Details ablenken zu lassen. Denn Events sind keine Logeinträge – sie sind die Sprache der Fachlichkeit.


(mai)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Software Testing: Qualität ist kein Zufall


In dieser Episode sprechen Richard Seidl und Florian Fieber über den besonderen Anlass, dass Seidl mit dem Deutschen Preis für Softwarequalität ausgezeichnet wurde. Diese Auszeichnung bietet den Rahmen, um über die Rolle des Menschen in der Technologieentwicklung nachzudenken. Richard Seidl teilt seine Sichtweise, dass Qualität weit über Testdaten und Skripte hinausgeht und dass es darum geht, ein Umfeld zu schaffen, in dem Teams Qualität aktiv leben.

Seidl und Fieber diskutieren auch die zukünftigen Herausforderungen und Möglichkeiten, die sich durch die Integration von KI im Bereich Testing ergeben.

„Wenn ein Team wirklich Qualität lebt und nicht nur Testfälle schrubbt, dann ist das ganze Thema auf einem völlig anderen Level angekommen.“ – Richard Seidl

Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Qualität ist kein Zufall – Richard Seidl“ und steht auf YouTube bereit.


(mai)



Source link

Weiterlesen

Entwicklung & Code

Apple übernimmt Entwickler des Open Policy Agents


Open Policy Agent (OPA) ist eine Software, die Regeln (formuliert in der Sprache Rego) und Datenobjekte entgegennimmt und auf dieser Grundlage Entscheidungen trifft – Haupteinsatzgebiet sind Autorisierungsregeln, die die Frage beantworten, ob ein Nutzer eine Aktion ausführen darf. Weil OPA Open-Source-Software ist (Apache License 2.0) und vergleichsweise leicht in andere Anwendungen integriert werden kann, erfreut er sich großer Beliebtheit in der Cloud-Native-Community: OPA wird unter anderem genutzt, um über Anfragen ans Kubernetes-API zu entscheiden, trifft in Banken aber auch Entscheidungen, wer welche Anfragen an interne Systeme stellen darf.

Erfunden wurde OPA vom Unternehmen Styra, das mit Zusatzprodukten und Dienstleistungen rund um OPA Geld verdient hat. Auf der Homepage findet man die Logos von Zalando, CapitalOne und dem Europäischen Patentamt. Auch Goldman Sachs und Netflix gehört zu den OPA-Nutzern. Der Code von OPA selbst liegt aber nicht mehr in der Hand von Styra: 2018 wurde OPA als Incubating-Projekt von der CNCF (Cloud Native Computing Foundation) akzeptiert, seit 2021 hat es den höchsten Status „Graduated“ erreicht und hat insgesamt 485 Contributors.

Jetzt steht der nächste Umbruch an: Die Erfinder von Open Policy Agent sowie weitere Mitarbeiter des Unternehmens Styra wechseln den Arbeitgeber: Apple, ebenfalls OPA-Nutzer, übernimmt Styra-CTO Tim Hinrichs und weitere Entwickler. Das hat Hinrichs im OPA-Blog verkündet. „Apple ist ein enthusiastischer OPA-Nutzer, der es als zentrale Komponente seiner Autorisationsinfrastruktur nutzt, um ein großes Portfolio globaler Clouddienste zu verwalten.“

Weil der Code bereits in der Hand der CNCF liegt, ändert sich das Open-Source-Projekt nichts. Der Code bleibt Open Source und wird wie zuvor von der CNCF verwaltet. Auch die Liste der Maintainer soll sich nicht ändern. Neu ist vielmehr, dass Zusatzprodukte aus dem Styra-Portfolio ebenfalls Open Source werden und ins öffentliche Repository umziehen: die kommerzielle OPA-Distribution EOPA, die Verwaltungsoberfläche „OPA Control Plane“, mehrere SDKs sowie der Rego-Linter namens Regal.

Website und Rego-Playground (eine Website, um Rego-Regeln zu testen) sollen wie gewohnt weiterlaufen und auch die Entwicklung soll weitergehen. Unklar hingegen ist, in welcher Form das Unternehmen Styra weiterarbeiten wird. Dazu macht der Blogpost keine Angaben. Große Organisationen, die gehofft haben, bei Styra die Autorisierungsexpertise und Beratung von Tim Hinrichs und den anderen OPA-Kernentwicklern einkaufen zu können, gehen leer aus: Diese Expertise nutzt jetzt Apple.


(jam)



Source link

Weiterlesen

Entwicklung & Code

software-architektur.tv: Netflix ohne Bounded Contexts


In der Softwarearchitektur gilt: Systeme lassen sich besser warten und flexibler gestalten, wenn man sie in mehrere Bounded Contexts aufteilt – und das ist gerade bei Microservices-Systemen entscheidend. Doch nun hat ausgerechnet Netflix, ein Pionier der Microservices-Bewegung, einen Blogpost veröffentlicht, der einen ganz anderen Weg propagiert: „Model Once, Represent Everywhere: UDA (Unified Data Architecture)„.

In dieser Episode nimmt Eberhard Wolff den Ansatz von Netflix genauer unter die Lupe und diskutiert, ob die Zeit gekommen ist, die Idee klar getrennter Bounded Contexts infrage zu stellen – und stattdessen auf ein zentrales Modell zu setzen.

Lisa Maria Schäfer malt dieses Mal keine Sketchnotes.

Livestream am 22. August

Die Ausstrahlung findet live am Freitag, 22. August 2025, 13 bis 14 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat, Bluesky, Mastodon, Slack-Workspace oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zur Folge finden sich auf der Videocast-Seite.


(mdo)



Source link

Weiterlesen

Beliebt