meldestelle/infrastructure/event-store/README-INFRA-EVENT-STORE.md

Infrastructure/Event-Store Module

Überblick

Das Event-Store-Modul ist eine kritische Komponente der Infrastruktur, die für die Persistenz und Veröffentlichung von Domänen-Events zuständig ist. Es bildet die technische Grundlage für Event Sourcing und eine allgemeine event-getriebene Architektur. Anstatt nur den aktuellen Zustand einer Entität zu speichern, speichert der Event Store die gesamte Kette von Ereignissen (Events), die zu diesem Zustand geführt haben.

Architektur: Port-Adapter-Muster

Wie schon das Cache-Modul, folgt auch der Event Store streng dem Port-Adapter-Muster, um eine maximale Entkopplung von der konkreten Speichertechnologie zu erreichen.

infrastructure/event-store/ ├── event-store-api/ # Der "Port": Definiert die Event-Store-Schnittstelle └── redis-event-store/ # Der "Adapter": Implementiert die Schnittstelle mit Redis Streams

event-store-api

Dieses Modul ist der abstrakte "Port" der Architektur. Es definiert den Vertrag, wie der Rest der Anwendung mit dem Event Store interagiert.

• Zweck: Definiert Interfaces wie EventStore (zum Speichern und Laden von Event-Streams) und EventPublisher (zum Veröffentlichen von Events an interessierte Listener). Es ist eng mit den DomainEvent-Definitionen aus dem :core:core-domain-Modul verknüpft.
• Vorteil: Die Fach-Services (z.B. members-application) sind vollständig von der Implementierung des Event Stores entkoppelt. Sie wissen nicht, ob die Events in Redis, Kafka oder einer relationalen Datenbank gespeichert werden.

redis-event-store

Dieses Modul ist der konkrete "Adapter", der die in event-store-api definierten Schnittstellen implementiert.

• Zweck: Stellt eine Implementierung des EventStore bereit, die Redis Streams als zugrunde liegenden Datenspeicher verwendet. Redis Streams sind eine leistungsstarke Datenstruktur, die sich ideal für die Implementierung eines append-only Logs eignet, wie es für einen Event Store benötigt wird.
• Technologie: Nutzt Spring Data Redis und den Lettuce-Client für die performante Kommunikation mit Redis. Die Domänen-Events werden vor der Speicherung mittels Jackson in ein JSON-Format serialisiert.
• Vorteil: Kapselt die gesamte Redis-spezifische Logik. Ein zukünftiger Wechsel zu einem anderen Event-Store-System (z.B. Apache Kafka) würde nur den Austausch dieses einen Moduls erfordern.

Verwendung in anderen Modulen

Ein Anwendungs-Service, der Event Sourcing verwendet, interagiert wie folgt mit dem Modul:

1. Abhängigkeit deklarieren: Das Service-Modul (z.B. members-application) fügt eine implementation-Abhängigkeit zu :infrastructure:event-store:redis-event-store in seiner build.gradle.kts hinzu.

2. Interface injizieren: Im Service-Code wird nur das EventStore-Interface aus der event-store-api injiziert.

   // In einem Use Case oder Application Service
   @Service
   class MemberApplicationService(
       private val eventStore: EventStore, // Nur das Interface wird verwendet!
       private val eventPublisher: EventPublisher
   ) {
       fun registerNewMember(command: RegisterMemberCommand): Member {
           // 1. Geschäftslogik ausführen und ein oder mehrere Events erzeugen
           val memberRegisteredEvent = MemberRegisteredEvent(
               memberId = UUID.randomUUID(),
               name = command.name,
               // ...
           )
   
           // 2. Das Event im Event Store speichern
           eventStore.save(memberRegisteredEvent)
   
           // 3. Das Event veröffentlichen, damit andere Teile des Systems
           // (z.B. ein E-Mail-Service) darauf reagieren können.
           eventPublisher.publish(memberRegisteredEvent)
   
           // ...
       }
   }
   

Diese Architektur ermöglicht eine hochgradig entkoppelte, skalierbare und resiliente Systemlandschaft, die auf asynchroner Kommunikation basiert.

---

Letzte Aktualisierung: 31. Juli 2025