7 Events, Commands und Messages – begriffliche Trennung

Die präzise Verwendung von Begriffen ist in Event-Driven Architecture von entscheidender Bedeutung. Wenn Teams beginnen, event-getriebene Systeme zu entwickeln, entstehen häufig Verwirrungen, weil die Begriffe “Event”, “Command” und “Message” unscharf verwendet werden. Diese begriffliche Unklarheit führt nicht nur zu Kommunikationsproblemen, sondern auch zu fehlerhaften Systemdesigns.

Beispiel: “Der Bestellservice sendet eine Message an das Zahlungssystem.” Handelt es sich um einen Command “VerarbeiteZahlung”, der explizit sagt, was zu tun ist? Oder um ein Event “BestellungAufgegeben”, das meldet, was passiert ist? Diese Unterscheidung hat weitreichende Auswirkungen auf Kopplung, Skalierbarkeit und Wartbarkeit.

7.1 Command vs. Event vs. Query

Jede Kommunikation in einem System kann einer von drei Absichten zugeordnet werden: etwas bewirken (Command), über etwas informieren (Event), oder wissen, was der aktuelle Zustand ist (Query).

7.1.1 Grundlegende Unterschiede

7.1.2 E-Commerce-Beispiel: Bestellprozess

Command-Beispiel:

ErstelleBestellung {
  kundenId: "K12345",
  artikel: [{"id": "P001", "menge": 2}],
  lieferadresse: {...}
}
→ Kann fehlschlagen (nicht verfügbar, ungültige Daten)

Event-Beispiel:

BestellungErstellt {
  bestellId: "B78910",
  kundenId: "K12345", 
  artikel: [{"id": "P001", "menge": 2}],
  zeitstempel: "2025-01-15T10:30:00Z"
}
→ Unveränderlicher Fakt, mehrere Services reagieren

Query-Beispiel:

ZeigeBestellhistorie {
  kundenId: "K12345",
  zeitraum: "letzteWoche"
}
→ Synchrone Antwort mit Bestelldaten

7.1.3 Kommunikationsmuster

7.2 Event-Typen und Semantik

Nicht alle Events sind gleich. Die verschiedenen Event-Typen haben unterschiedliche Semantiken und Verwendungszwecke:

7.2.1 Event-Kategorien

7.2.2 Event-Design-Prinzipien

7.3 Message-Kategorisierung und Verwendungszwecke

Für effektives Design müssen Messages nach verschiedenen Kriterien kategorisiert werden:

7.3.1 Temporale Klassifizierung

7.3.2 Umfang und Reichweite

7.3.3 Priorität und Service Level

7.3.4 Verarbeitungseigenschaften

7.3.5 Praktische Design-Guidelines

Commands verwenden für:

• Direkte Benutzeraktionen (Button-Clicks)
• Explizite Geschäftsoperationen
• Operationen, die fehlschlagen können
• 1:1 Service-Kommunikation

Events verwenden für:

• Geschäftsereignisse dokumentieren
• Lose gekoppelte Service-Integration
• Audit-Trails und Compliance
• 1:n Benachrichtigungen

Queries verwenden für:

• Datenabfragen ohne Seiteneffekte
• User Interface Updates
• Reporting und Analytics
• Sofortige Antworten erforderlich

7.3.6 Message-Design-Checkliste

Die klare begriffliche Trennung zwischen Events, Commands und Queries bildet das konzeptionelle Rückgrat erfolgreicher event-getriebener Architekturen. Wenn Teams diese Konzepte verinnerlicht haben, entstehen Systeme, die nicht nur technisch robust sind, sondern auch die Geschäftslogik klar abbilden.