Spring-Boot-Gegenstueck zu novaris-legacy-parent/novaris-notification-jms. Zwei unabhaengige
Abonnenten desselben Kafka-Topics - zeigt Publish/Subscribe im Kontrast zum Request/Reply in
novaris-claims-modern, siehe docs/70-migration/03-messaging-jms-zu-kafka.md.
PolicyDocumentGenerationListener - Kafka-Gegenstueck zu PolicyDocumentGenerationMDB,
eigene Consumer-Group, filtert clientseitig auf POLICY_ISSUED.CustomerNotificationListener - Kafka-Gegenstueck zu CustomerNotificationMDB, eigene
Consumer-Group, filtert clientseitig auf POLICY_ISSUED UND CLAIM_REGISTERED.Zentraler Unterschied zum JMS-Original: Kafka kennt keine serverseitigen Message-Selektoren - beide Consumer-Groups erhalten alle Ereignisse des Topics und filtern selbst nach dem Empfang (siehe Javadoc beider Klassen).
Seit Migrationsphase M6: Micrometer-Tracing fuer beide Listener aktiviert (siehe
docs/70-migration/10-observability-tracing.md) - inklusive des dort dokumentierten,
real gefundenen Bugs (fehlender Zipkin-Sender-Fallback ohne spring-boot-starter-web).
# aus novaris-modern-parent/:
mvn -pl novaris-notification-modern -am test
NotificationTopicFanoutTest (Kafka-Gegenstueck zu NotificationTopicFanoutTest im
Legacy-Teil) beweist die eigentliche Publish/Subscribe-Mechanik gegen einen echten
eingebetteten Kafka-Broker - dieselbe POLICY_ISSUED-Nachricht erreicht beide Abonnenten,
eine CLAIM_REGISTERED-Nachricht nur den Customer-Notification-Abonnenten.