Spring AMQP und RabbitMQ

• Exchange, Queue und Binding.
• RabbitTemplate für Publisher.
• @RabbitListener für Consumer.
• MessageConverter und RetryInterceptor.
• Dead Letter Exchange und TTL.

• Du brauchst Work Queues oder Routing nach Topic/Headers.
• Du migrierst JMS-artige Queue-Kommunikation.
• Du willst einfache, robuste asynchrone Jobs.

• RabbitMQ wie Kafka verwenden wollen.
• Keine DLQ oder Poison-Message-Strategie.
• Unbegrenzte Prefetch-Werte erzeugen Speicher-/Fairness-Probleme.

IBM MQ/JMS Use Cases können oft zu RabbitMQ-Queues migriert werden, sofern Transaktions- und Zustellgarantien neu bewertet werden.

Das Beispiel zeigt bewusst nicht nur Annotationen, sondern auch die Verantwortung der Schicht. In echten Projekten sollte der technische Spring-Code an Adapter- oder Konfigurationsrändern bleiben, während die Fachlogik testbar und möglichst frameworkarm bleibt.

@Configuration
class ShippingAmqpConfiguration {
    @Bean Queue shippingQueue() { return QueueBuilder.durable("shipping.commands").build(); }
    @Bean DirectExchange exchange() { return new DirectExchange("order.exchange"); }
    @Bean Binding binding(Queue shippingQueue, DirectExchange exchange) {
        return BindingBuilder.bind(shippingQueue).to(exchange).with("ship");
    }
}

@Component
class ShippingListener {
    @RabbitListener(queues = "shipping.commands")
    void handle(ShipOrderCommand command) {
        shippingService.ship(command.orderId());
    }
}

• Ist die Verantwortung des Bausteins klar: Framework steuert Lebenszyklus, Library wird gezielt benutzt?
• Ist die Fachlogik außerhalb von Controller, Listener, Repository-Implementierung oder Konfiguration?
• Sind Fehlerfälle, Timeouts, Security, Monitoring und Tests sichtbar modelliert?
• Gibt es klare Grenzen zwischen DTO, Domäne, Persistence und Infrastruktur?