Implementere en Kafka-adapter, der kan publicere events på et nyt, dedikeret topic. Skrive UnitTests, der kan bidrage til at kvalitetssikre driften af microservicen.

Jeg har arbejdet ud fra Ports & Adapters (Hexagonal Architecture), hvor applikationslaget kun kommunikerer med abstraktioner (interfaces). Den konkrete Kafka implementering placeres som en adapter i Infrastruktur-laget og registreres via Dependency Injection.

Dependency Injection, Port og Adapter

Klassen RecognitionCompletedKafkaProducer implementerer interfacet IRecognitionCompletedPublisher. På den måde forholder applikationslaget sig kun til en port og kender ikke den konkrete teknologi (Kafka). Adapteren er internal sealed, da den kun skal bruges i Infrastruktur-laget og ikke nedarves.

Denne arkitektur giver:

• Mulighed for at skifte message broker (fx Kafka → RabbitMQ) uden at ændre domænelogik.
• Testbarhed, da eksterne afhængigheder kan mockes.
• Klar opdeling mellem domæne og infrastruktur (Separation of Concerns).

Publicering af event (kerneflow)

I publiseringsflowet mappes domænedata først til en ekstern event-kontrakt, hvorefter eventet serialiseres og sendes til det konfigurerede topic. Dermed holdes domænelag og message broker-lag adskilt.

Unit Test (Adfærdsdrevet test af publish-flow)

I unit testen mockes både serializer og Kafka-produceren. Dette giver en deterministisk test, hvor adfærden verificeres uden at have en kørende Kafka-broker.

Testen verificerer:

• at serialisering udføres én gang
• at eventet sendes til det forventede topic
• at key og payload stemmer overens med domænedata
• at beskeden sendes præcis én gang for at undgå duplikering

Jeg har lært, hvordan man adskiller domænelogik fra infrastruktur ved hjælp af ports, interfaces og dependency injection. Selvom der primært arbejdes med DTO’er, har øvelsen gjort det tydeligt, hvordan applikationslaget kan holdes helt frit for teknologivalg som Kafka. Det betyder, at message broker eller transportlag kan udskiftes uden at påvirke logikken i microservicen.

Jeg har også styrket min forståelse af, hvordan en adapter bygges, så den kun har ansvar for én ting: at publicere et event i korrekt format til message brokeren. Denne separation gør koden mere robust, vedligeholdelsesvenlig og testbar.

Desuden har jeg lært at skrive enhedstests, der tester den forventede adfærd frem for implementationen. Ved at mocke både serializer og Kafka-producer kan testen fokusere på, om det rigtige event bliver sendt til det rigtige topic, og ikke på den tekniske kommunikation med Kafka. Det gør testene stabile og uafhængige af eksterne systemer.