PhilKa: Die Seite wurde neu angelegt: „= Event-Driven Architecture (EDA) = Die '''Event-Driven Architecture''' (kurz: '''EDA''', deutsch: '''Ereignisgesteuerte Architektur''') ist ein '''Architekturstil''' in der Softwareentwicklung, bei dem der Informationsfluss durch das '''Eintreten und die Verarbeitung von Ereignissen''' gesteuert wird. Anstatt dass Komponenten direkt miteinander interagieren, kommunizieren sie über '''Ereignisse''' (''Events''), die von einem oder mehreren '''Event-H…“

2025-10-30T11:44:56Z

Die Seite wurde neu angelegt: „= Event-Driven Architecture (EDA) = Die '''Event-Driven Architecture''' (kurz: '''EDA''', deutsch: '''Ereignisgesteuerte Architektur''') ist ein '''Architekturstil''' in der Softwareentwicklung, bei dem der Informationsfluss durch das '''Eintreten und die Verarbeitung von Ereignissen''' gesteuert wird. Anstatt dass Komponenten direkt miteinander interagieren, kommunizieren sie über '''Ereignisse''' (''Events''), die von einem oder mehreren '''Event-H…“

Neue Seite

= Event-Driven Architecture (EDA) =

Die '''Event-Driven Architecture''' (kurz: '''EDA''', deutsch: '''Ereignisgesteuerte Architektur''') ist ein '''Architekturstil''' in der Softwareentwicklung, bei dem der Informationsfluss durch das '''Eintreten und die Verarbeitung von Ereignissen''' gesteuert wird.

Anstatt dass Komponenten direkt miteinander interagieren, kommunizieren sie über '''Ereignisse''' (''Events''), die von einem oder mehreren '''Event-Handlern''' oder '''Subscribers''' verarbeitet werden.

== Grundprinzip ==

Im Zentrum der ereignisgesteuerten Architektur steht die Idee, dass Systeme auf das '''Eintreten von Ereignissen''' reagieren, anstatt zyklisch Zustände zu prüfen oder direkt Funktionen aufzurufen.

Ein „Event“ ist dabei eine Nachricht, die signalisiert, dass etwas passiert ist (z. B. „Bestellung eingegangen“, „Sensorwert geändert“, „Benutzer klickte auf Button“).

<pre>
+--------------------+ +--------------------+ +--------------------+
| Event Source | -----> | Event Broker | -----> | Event Handler |
| (Producer/Sender) | | (Message Queue) | | (Consumer/Listener)|
+--------------------+ +--------------------+ +--------------------+
</pre>

== Hauptkomponenten ==
{| class="wikitable"
! Komponente !! Beschreibung
|-
| '''Event Producer''' || Erzeugt Ereignisse (z. B. Benutzeraktionen, Sensoren, Microservices)
|-
| '''Event Channel / Broker''' || Transportiert Ereignisse asynchron (z. B. Message Queue, Event Bus)
|-
| '''Event Consumer''' || Reagiert auf bestimmte Ereignisse und führt entsprechende Aktionen aus
|-
| '''Event Store''' || Optionale persistente Speicherung vergangener Ereignisse (z. B. für Event Sourcing)
|}

== Ablauf ==
1. Ein Producer erzeugt ein Event („Bestellung wurde aufgegeben“).
2. Das Event wird an einen Broker (z. B. RabbitMQ, Kafka) gesendet.
3. Der Broker leitet das Event an alle interessierten Consumer weiter.
4. Jeder Consumer reagiert unabhängig auf das Ereignis.

== Beispiel in Pseudo-C++ ==
Ein vereinfachtes Beispiel für ein ereignisgesteuertes System:

<syntaxhighlight lang="cpp">
#include <iostream>
#include <functional>
#include <map>
#include <vector>
#include <string>

class EventBus {
std::map<std::string, std::vector<std::function<void(std::string)>>> subscribers;
public:
void subscribe(const std::string& event, std::function<void(std::string)> handler) {
subscribers[event].push_back(handler);
}

void publish(const std::string& event, const std::string& data) {
for (auto& handler : subscribers[event]) {
handler(data);
}
}
};

int main() {
EventBus bus;

// Subscriber registrieren
bus.subscribe("order_created", [](std::string msg){
std::cout << "E-Mail-Service: Sende Bestellbestätigung für " << msg << std::endl;
});

bus.subscribe("order_created", [](std::string msg){
std::cout << "Lager-Service: Reserviere Artikel für " << msg << std::endl;
});

// Event auslösen
bus.publish("order_created", "Bestellung #1234");
}
</syntaxhighlight>

Ergebnis:
<pre>
E-Mail-Service: Sende Bestellbestätigung für Bestellung #1234
Lager-Service: Reserviere Artikel für Bestellung #1234
</pre>

== Architekturmuster ==
Ereignisgesteuerte Architekturen lassen sich in verschiedene Unterarten gliedern:

=== 1. Einfaches Event-Notification-Modell ===
Ein Sender informiert Empfänger direkt über ein Ereignis (z. B. [[Observer-Entwurfsmuster]]).

=== 2. Event-Carried State Transfer ===
Das Event enthält die notwendigen Daten, damit Empfänger unabhängig agieren können.

=== 3. Event Sourcing ===
Zustände werden nicht direkt gespeichert, sondern als Abfolge von Ereignissen (z. B. „Konto eröffnet“, „Geld eingezahlt“).
Der aktuelle Zustand wird aus allen Events rekonstruiert.

=== 4. Complex Event Processing (CEP) ===
Systeme analysieren Muster in einer Vielzahl von Ereignissen in Echtzeit (z. B. Anomalieerkennung, IoT-Systeme).

== Vorteile ==
* Hohe **Entkopplung** zwischen Komponenten
* Bessere **Skalierbarkeit** und **Asynchronität**
* Gute **Erweiterbarkeit** – neue Event-Handler können leicht hinzugefügt werden
* Ideal für **Microservices** und **verteilte Systeme**

== Nachteile ==
* Komplexeres Debugging und Monitoring
* Schwierige Transaktions- und Konsistenzsicherung
* Höherer Aufwand für Event-Schema-Management
* Event-Reihenfolge und -Duplikate müssen berücksichtigt werden

== Typische Implementierungen ==
* Message Broker / Event Bus Systeme:
* **Apache Kafka**
* **RabbitMQ**
* **ActiveMQ**
* **AWS SNS/SQS**
* **Azure Event Hub**
* Asynchrone Frameworks:
* **Node.js (Event Loop)**
* **Boost.Asio (C++)**
* **.NET Event System**
* **Akka (Scala/Java)**

== Vergleich zu anderen Architekturstilen ==
{| class="wikitable"
! Architekturstil !! Merkmale !! Kommunikation
|-
| [[Service-Oriented Architecture (SOA)]] || Dienste kommunizieren direkt über Schnittstellen || synchron (Request/Response)
|-
| '''Event-Driven Architecture''' || Dienste reagieren auf Ereignisse || asynchron (Publish/Subscribe)
|-
| [[Reactor-Entwurfsmuster]] || Low-Level-Ereignissteuerung (z. B. Socket-I/O) || synchron, nicht-blockierend
|-
| [[Observer-Entwurfsmuster]] || Lokales Ereignissystem in Objektorientierung || direkt in einer Anwendung
|}

== Beispielhafte Anwendungsbereiche ==
* Microservices-Kommunikation
* IoT- und Sensordatenverarbeitung
* Finanztransaktionen und Echtzeit-Analysen
* Logging- und Monitoring-Systeme
* Chat- oder Benachrichtigungssysteme

== Erweiterte Konzepte ==
* '''Event Choreography:''' Dienste reagieren eigenständig auf Events (dezentrale Logik)
* '''Event Orchestration:''' Zentrale Steuerung der Reaktionen auf Events (z. B. via Workflow Engine)
* '''Event Replay:''' Nachträgliches Wiederholen von Events für Auditing oder Recovery
* '''Idempotenz:''' Sicherstellung, dass doppelt verarbeitete Events keine fehlerhaften Zustände erzeugen

== Beispielhafte Kombination mit Entwurfsmustern ==
* [[Observer-Entwurfsmuster]] – lokale Implementierung innerhalb eines Prozesses
* [[Reactor-Entwurfsmuster]] – effiziente Ereignisverarbeitung auf Systemebene
* [[Proactor-Entwurfsmuster]] – asynchrone Verarbeitung von I/O-Ereignissen
* [[Mediator-Entwurfsmuster]] – Koordination von Events über zentrale Vermittler

== Siehe auch ==
* [[Observer-Entwurfsmuster]]
* [[Reactor-Entwurfsmuster]]
* [[Proactor-Entwurfsmuster]]
* [[Publisher-Subscriber-Muster]]
* [[Service-Oriented Architecture (SOA)]]
* [[Microservices-Architektur]]

== Quellen ==
* O. Zimmermann et al.: *Architectural Decisions for Event-Driven Architectures*, IEEE Software (2020)
* Martin Fowler: [https://martinfowler.com/articles/201701-event-driven.html What do you mean by “Event-Driven”?]
* [https://en.wikipedia.org/wiki/Event-driven_architecture Wikipedia: Event-Driven Architecture]
* *Enterprise Integration Patterns* – Gregor Hohpe, Bobby Woolf (2003)

Event-Driven Architecture (EDA) - Versionsgeschichte