DEV Community: Luciano Azevedo

Consuming RabbitMQ Messages as Background Jobs in .NET with NexJob

Luciano Azevedo — Wed, 28 Oct 2026 14:39:15 +0000

A couple of weeks ago, I posted about consuming Kafka events as background jobs in .NET. Today, let's look at RabbitMQ.

Writing a basic RabbitMQ consumer in C# looks easy on tutorials: you create a connection, open a channel, attach an EventingBasicConsumer or AsyncDefaultBasicConsumer, and handle messages.

Then you run it in production, and edge cases start piling up:

Long-running processing blocks the consumer. If a message takes 30 seconds to process (like calling a slow third-party API or generating a PDF), RabbitMQ's consumer_timeout (default 30 minutes in newer versions, or much less if configured) can fire and drop your channel. Worse, prefetching messages while one thread is stuck can starve other consumers.
The Ack dilemma. If you ack the message as soon as it arrives, you lose data when the worker crashes halfway through. If you hold the ack until everything finishes, an unexpected crash re-delivers the message, causing duplicate side effects unless you hand-roll deduplication everywhere.
Storage/database blips crash the channel. If your database is restarting, your handler throws an unhandled exception. In RabbitMQ, an unhandled exception inside the consumer callback often closes the AMQP channel. You have to write reconnection and channel recreation logic yourself.
Broken trace context. Your incoming API request had a W3C traceparent. Once it went through RabbitMQ, your background logs and spans in OpenTelemetry / Jaeger are completely detached.

Instead of keeping connections open while doing heavy processing, a much cleaner pattern is to treat RabbitMQ as an ingress trigger: pull the message, persist it into durable job storage (Postgres, SQL Server, Redis, Mongo), ack it immediately to the broker, and let a dedicated background job executor handle the heavy lifting, retries, and dead-lettering.

Here is how we do that with NexJob.RabbitMQ.

1. Setting Up the Trigger

Install the package:

dotnet add package NexJob.RabbitMQ
dotnet add package NexJob.PostgreSQL # or Redis, SqlServer, Mongo, InMemory

In your Program.cs, wire up NexJob with your preferred storage, and register the RabbitMQ trigger bound to a job type:

using NexJob;
using NexJob.RabbitMQ;

var builder = WebApplication.CreateBuilder(args);

// Storage provider (Postgres here, but any NexJob provider works)
builder.Services.AddNexJobPostgres(builder.Configuration.GetConnectionString("NexJob")!);

// Register NexJob core and bind the RabbitMQ trigger to our job handler
builder.Services.AddNexJob()
    .AddRabbitMqTrigger<ProcessOrderJob>(options =>
    {
        options.HostName = builder.Configuration["RabbitMQ:Host"] ?? "localhost";
        options.Port = 5672;
        options.UserName = builder.Configuration["RabbitMQ:User"] ?? "guest";
        options.Password = builder.Configuration["RabbitMQ:Pass"] ?? "guest";
        options.QueueName = "incoming-orders";
        options.TargetQueue = "orders"; // internal NexJob queue priority/partition
        options.PrefetchCount = 20;
    });

var app = builder.Build();
app.Run();

2. Writing the Job Handler

The job handler implements IJob<string>. The incoming RabbitMQ payload is passed directly as the input string (typically JSON):

using System.Text.Json;
using NexJob;

public sealed class ProcessOrderJob(ILogger<ProcessOrderJob> logger, IPaymentGateway paymentGateway) 
    : IJob<string>
{
    public async Task ExecuteAsync(IJobContext context, string input, CancellationToken ct)
    {
        var order = JsonSerializer.Deserialize<OrderPayload>(input)!;

        logger.LogInformation("Processing order {OrderId} (Attempt {Attempt})", 
            order.OrderId, context.Attempt);

        // Run your business logic safely.
        // If this throws or crashes, RabbitMQ is already freed up.
        // NexJob manages retry delays, backoff, and dead-lettering.
        await paymentGateway.ChargeAsync(order.CustomerId, order.Amount, ct);
    }
}

public sealed record OrderPayload(Guid OrderId, Guid CustomerId, decimal Amount);

3. What Happens Under the Hood

When a message hits incoming-orders, here is the exact sequence:

[ RabbitMQ Queue ]
       │
       ▼
[ NexJob RabbitMQ Trigger ]
       │  1. Reads W3C 'traceparent' header -> injects into JobRecord.TraceParent
       │  2. Uses broker's MessageId as IdempotencyKey (duplicate delivery protection)
       │  3. Calls IScheduler.EnqueueAsync(job)
       ▼
[ Durable Storage (Postgres/Redis/etc.) ]
       │
       ├─ If Commit OK: Trigger immediately sends BasicAck to RabbitMQ.
       │  RabbitMQ's job is done. The broker channel stays clean and free.
       │
       └─ If Storage Down: Trigger Nacks with requeue after 1s backoff.
          If message has no valid JobType: Trigger Nacks with requeue=false (moves to DLX).

The 4 Guarantees You Get for Free:

Broker Ack only after durable commit: The message is only acknowledged to RabbitMQ after the job record is safely written to the database. If your app dies before the commit, RabbitMQ still has the message.
Native Idempotency: The trigger uses RabbitMQ's native BasicProperties.MessageId as the job's IdempotencyKey. If a network hiccup causes RabbitMQ to redeliver the message, NexJob detects the duplicate and ignores it instead of double-charging your customer.
Trace Propagation: If the message producer passed a traceparent header, NexJob parses it and links the background execution to that exact distributed trace. In your dashboard or telemetry logs, you see the entire lifecycle end-to-end.
Channel Isolation: If ProcessOrderJob throws an exception, fails payment, or times out, it does not close your RabbitMQ channel or cause connection thrashing. It follows your NexJob retry policy (e.g., 3 retries with exponential backoff) and lands in the dead-letter queue in your dashboard if all retries fail.

4. What About Publishing? (The Outbox Producer)

Handling inbound messages is half the story. The other common failure point is publishing to RabbitMQ from your API handlers.

If you publish directly to RabbitMQ inside an HTTP endpoint:

What if the broker is restarting or temporarily unreachable?
What if RabbitMQ accepts the TCP connection but fails to persist the message to disk before acknowledging?

NexJob.RabbitMQ includes a resilient Outbox Producer with RabbitMQ Publisher Confirms built-in.

Registering the Producer:

builder.Services.AddNexJob()
    .AddRabbitMqProducer(options =>
    {
        options.HostName = builder.Configuration["RabbitMQ:Host"] ?? "localhost";
        options.DefaultExchange = "orders.exchange";
        options.ConfirmTimeout = TimeSpan.FromSeconds(5);
    });

Enqueuing Messages via `IScheduler`:

Instead of dealing with IConnection or IChannel pools in your controllers or services, inject IScheduler:

[ApiController]
[Route("orders")]
public class OrdersController(IScheduler scheduler) : ControllerBase
{
    [HttpPost]
    public async Task<IActionResult> CreateOrder([FromBody] CreateOrderRequest request, CancellationToken ct)
    {
        var orderEvent = new OrderCreatedEvent(Guid.NewGuid(), request.Amount);

        // Enqueues as a reliable background job. 
        // Persisted to database first, then delivered to RabbitMQ with Publisher Confirms.
        await scheduler.EnqueueRabbitMqAsync(
            exchange: "orders.exchange",
            routingKey: "order.created",
            value: orderEvent,
            correlationId: orderEvent.OrderId.ToString(),
            cancellationToken: ct);

        return Accepted(new { orderEvent.OrderId });
    }
}

How this works:

scheduler.EnqueueRabbitMqAsync saves a small job record in your database.
NexJob's background dispatcher picks it up, opens a channel with ConfirmSelect() enabled, and publishes the message.
The job succeeds only after RabbitMQ responds with an ACK (confirming it saved the message).
If RabbitMQ responds with a NACK or times out, the job fails, backs off, and retries automatically. You never drop messages due to broker blips.

5. Monitoring in the Dashboard

If you use NexJob.Dashboard or NexJob.Dashboard.Standalone, you don't need to guess what is happening:

You can see incoming trigger jobs, their retry counts, and execution latency.
The W3C traceparent and MessageId are visible and copyable right from the job details page.
Outbox publishing jobs show up with their delivery attempts and publisher confirm status.

Summary

Handling messaging in production is rarely about the protocol; it's about handling partial failures cleanly.

By using NexJob as the intermediary:

RabbitMQ handles queue distribution and routing.
NexJob handles persistence, retries, dead-lettering, and distributed tracing.
Your application code stays clean: just an IJob<string> implementation and normal IScheduler calls.

If you want to check out the project or see more samples, here is the repo:
👉 GitHub: oluciano/NexJob

Have you hit issues with long-running consumers in RabbitMQ before? How do you currently decouple queue consumption from job execution in your .NET services?

Consuming Kafka events as background jobs in .NET with NexJob

Luciano Azevedo — Sun, 18 Oct 2026 18:54:02 +0000

When a message arrives on a Kafka topic, processing it directly inside your consumer loop has a well-known problem: if the handler is slow or makes external network calls, you risk exceeding max.poll.interval.ms and causing a partition rebalance. If the handler fails halfway through, you either commit the offset and lose the work, or crash the consumer loop.

A standard pattern to solve this is to decouple ingestion from execution: read the message, persist it immediately as a background job, commit the Kafka offset, and let worker slots process it with retries and dead-lettering.

This post sets up a Kafka consumer in .NET that turns incoming topic messages into NexJob background jobs.

What you need

The .NET 8 or 10 SDK
A running Kafka broker (e.g., localhost:9092)

1. A project and packages

Create a worker service or API project:

dotnet new worker -n KafkaWorker
cd KafkaWorker
dotnet add package NexJob
dotnet add package NexJob.Kafka

NexJob.Kafka bundles both the consumer trigger and the outbox producer in a single library.

2. Write the job

A consumer trigger hands the raw message payload to a job implementing IJob<string>.

using System.Text.Json;
using NexJob;

public sealed record OrderPlacedEvent(Guid OrderId, decimal Amount, string CustomerEmail);

public sealed class ProcessOrderJob : IJob<string>
{
    private readonly ILogger<ProcessOrderJob> _logger;

    public ProcessOrderJob(ILogger<ProcessOrderJob> logger) => _logger = logger;

    public Task ExecuteAsync(string payload, CancellationToken ct)
    {
        var order = JsonSerializer.Deserialize<OrderPlacedEvent>(payload);
        if (order is null)
        {
            throw new InvalidOperationException("Failed to deserialize order payload.");
        }

        _logger.LogInformation("Processing order {OrderId} for {Amount:C}", order.OrderId, order.Amount);

        // Your business logic here: charge card, update database, call API
        return Task.CompletedTask;
    }
}

The job is resolved through dependency injection, so you can inject your DbContext, HTTP clients, or repositories into the constructor.

3. Register the Kafka trigger

In Program.cs, bind the topic to your job:

using NexJob;
using NexJob.Kafka;

var builder = Host.CreateApplicationBuilder(args);

// Register NexJob engine and the Kafka trigger
builder.Services.AddNexJob(opt =>
    {
        opt.Workers = 5; // Concurrent worker threads processing jobs
    })
    .AddKafkaTrigger<ProcessOrderJob>(opt =>
    {
        opt.BootstrapServers = "localhost:9092";
        opt.Topic = "orders";
        opt.GroupId = "orders-processor-group";
    })
    .AddNexJobJobs(typeof(Program).Assembly);

var host = builder.Build();
await host.RunAsync();

AddKafkaTrigger<TJob> registers the consumer as a background service and automatically registers ProcessOrderJob as transient in your service container.

4. How offsets and retries work

A trigger does not execute the job directly inside the Kafka loop. The lifecycle works as follows:

Consume: The consumer reads a message batch from Kafka.
Store: Each message is enqueued into NexJob storage. The Kafka message key (or partition + offset) is used as the idempotency key, preventing duplicate jobs if a network glitch occurs.
Commit: The offset is committed to Kafka only after the job is safely written to storage.
Execute: A NexJob worker picks up the job from storage and runs ExecuteAsync.

If your business logic throws an exception inside ExecuteAsync:

The Kafka partition is not blocked; other messages continue to be consumed.
The job follows your NexJob retry policy (exponential backoff by default).
If retries are exhausted, the job moves to the dead-letter queue.

5. Publishing messages back to Kafka (Outbox pattern)

If your app also needs to produce messages reliably, NexJob.Kafka includes an outbox producer. Instead of making an in-flight network call to Kafka inside an HTTP request or database transaction, enqueue it through IScheduler:

app.MapPost("/orders", async (OrderPlacedEvent order, IScheduler scheduler) =>
{
    // Save to local database first, then enqueue Kafka message
    await scheduler.EnqueueKafkaAsync(
        topic: "orders",
        key: order.OrderId.ToString(),
        value: order);

    return Results.Accepted();
});

NexJob persists the message locally and delivers it to Kafka in the background with retry and guaranteed ordering per key.

Next steps

Using a database provider (NexJob.Postgres or NexJob.SqlServer) instead of in-memory storage for persistent guarantees across restarts.
Setting dead-letter alert topics with options.ExhaustedJobsTopic.
Monitoring consumers and worker slots using OpenTelemetry.

Source and samples: https://github.com/oluciano/NexJob
Documentation: https://oluciano.github.io/NexJob/

Your first background job in .NET with NexJob

Luciano Azevedo — Tue, 13 Oct 2026 12:57:29 +0000

Your first background job in .NET with NexJob

Sooner or later a web app needs to do something that should not block the request: send an e-mail, resize an image, call a slow API. This post builds the smallest possible background job in .NET 8 and runs it. No database, no extra services, about five minutes.

What you need

The .NET 8 SDK
A terminal

1. A project

dotnet new worker -n MyJobs
cd MyJobs
dotnet add package NexJob

A worker service is the simplest host. Everything below works the same inside an ASP.NET Core app.

2. Register NexJob

Two lines in Program.cs: one to add NexJob, one to let it find your job classes.

using NexJob;

var host = Host.CreateDefaultBuilder(args)
    .ConfigureServices(services =>
    {
        services.AddNexJob();
        services.AddNexJobJobs(typeof(Program).Assembly);
    })
    .Build();

Call AddNexJob() once. Calling it twice registers the background services twice.

3. Write the job

A job is a class with one method. Implement IJob when the work needs no input.

public sealed class HelloJob : IJob
{
    public Task ExecuteAsync(CancellationToken ct)
    {
        Console.WriteLine($"Hello at {DateTimeOffset.UtcNow:O}");
        return Task.CompletedTask;
    }
}

Two things worth knowing right away:

NexJob builds the job from your dependency injection container, so constructor injection works like anywhere else in .NET.
The CancellationToken is yours to honor. When the host shuts down, it is how the job finds out.

4. Enqueue it

Ask the container for IScheduler and enqueue the job.

await host.StartAsync();

var scheduler = host.Services.GetRequiredService<IScheduler>();
await scheduler.EnqueueAsync<HelloJob>();

await host.WaitForShutdownAsync();

5. Run it

dotnet run

Hello at 2026-10-13T12:33:27.9831829+00:00

That is the whole loop. The job was stored, picked up by a worker running inside your process, and executed. There is no separate worker process to deploy.

A job that takes input

Most real jobs need data. Implement IJob<T> and use a record for the input: it serializes cleanly and cannot change after it is enqueued.

public sealed record SendWelcomeEmailInput(string Email, string UserName);

public sealed class SendWelcomeEmailJob : IJob<SendWelcomeEmailInput>
{
    private readonly IEmailService _email;

    public SendWelcomeEmailJob(IEmailService email) => _email = email;

    public async Task ExecuteAsync(SendWelcomeEmailInput input, CancellationToken ct)
        => await _email.SendAsync(input.Email, $"Welcome, {input.UserName}!", ct);
}

await scheduler.EnqueueAsync<SendWelcomeEmailJob, SendWelcomeEmailInput>(
    new SendWelcomeEmailInput("user@example.com", "Jane"));

What happens if the process stops?

With the default storage, jobs live in memory and are gone when the process exits. That is fine for trying things out and for tests. For anything real, add a database provider:

dotnet add package NexJob.Postgres

services.AddNexJobPostgres("Host=localhost;Database=nexjob;Username=postgres;Password=secret");
services.AddNexJob();

Register the provider before AddNexJob(), so it replaces the in-memory default. SQL Server, Redis and MongoDB providers exist too.

Where to go next

Retries and what happens when a job keeps failing
Delays, recurring jobs and deadlines
Seeing what your jobs are doing (the next posts in this series)

Source and samples: https://github.com/oluciano/NexJob
Documentation: https://oluciano.github.io/NexJob/

🏗️ Aplicando Adapter e Decorator Patterns com Injeção de Dependência no C#

Luciano Azevedo — Sun, 02 Feb 2025 22:00:25 +0000

Ao desenvolver software, muitas vezes precisamos integrar sistemas legados e adicionar funcionalidades sem modificar diretamente o código existente. Para isso, podemos usar padrões de design como Adapter e Decorator, que nos ajudam a estruturar o código de forma modular e reutilizável.

Neste artigo, vamos explorar como usar esses padrões no C# com injeção de dependência (DI) e a biblioteca Scrutor para simplificar o registro dos decorators.

🎯 Cenário do Problema

Imagine que temos um serviço legado que processa pagamentos, mas ele não segue a interface moderna que queremos usar em nosso sistema. Além disso, queremos adicionar logs ao processamento de pagamentos sem modificar diretamente o serviço existente.

Vamos resolver isso combinando Adapter e Decorator!

📌 Passo 1: Definindo a Interface Padrão

Criamos a interface IPaymentProcessor para definir um contrato padrão para processadores de pagamento:

public interface IPaymentProcessor
{
    void ProcessPayment(decimal amount);
}

Essa interface será usada tanto pelo Adapter quanto pelo Decorator.

📌 Passo 2: Criando o Serviço Legado

Nosso serviço legado (LegacyPaymentService) não segue a interface moderna. Ele espera um string em vez de um decimal:

public sealed class LegacyPaymentService
{
    public void MakePayment(string amount)
    {
        Console.WriteLine($"Processing payment of {amount} via legacy system.");
    }
}

Para integrá-lo ao sistema moderno, usaremos o Adapter Pattern.

📌 Passo 3: Criando o Adapter

O Adapter faz a conversão entre IPaymentProcessor e LegacyPaymentService:

public sealed class PaymentAdapter : IPaymentProcessor
{
    private readonly LegacyPaymentService _legacyPaymentService;

    public PaymentAdapter(LegacyPaymentService legacyPaymentService)
    {
        _legacyPaymentService = legacyPaymentService;
    }

    public void ProcessPayment(decimal amount)
    {
        string amountString = amount.ToString("F2");
        _legacyPaymentService.MakePayment(amountString);
    }
}

Agora podemos usar PaymentAdapter em qualquer lugar que espera IPaymentProcessor.

📌 Passo 4: Criando o Decorator para Logging

Agora adicionamos um Decorator (LoggingDecorator) para registrar logs sempre que um pagamento for processado:

using Microsoft.Extensions.Logging;

public class LoggingDecorator : IPaymentProcessor
{
    private readonly IPaymentProcessor _innerProcessor;
    private readonly ILogger<LoggingDecorator> _logger;

    public LoggingDecorator(IPaymentProcessor innerProcessor, ILogger<LoggingDecorator> logger)
    {
        _innerProcessor = innerProcessor;
        _logger = logger;
    }

    public void ProcessPayment(decimal amount)
    {
        _logger.LogInformation($"Iniciando processamento do pagamento de {amount:C}");
        _innerProcessor.ProcessPayment(amount);
        _logger.LogInformation($"Pagamento de {amount:C} processado com sucesso.");
    }
}

Esse Decorator adiciona logs antes e depois da chamada real ao PaymentProcessor, sem modificar sua implementação.

📌 Passo 5: Criando o Worker Service

Para simular um sistema em execução contínua, criamos um Worker Service que chama IPaymentProcessor:

using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using System;
using System.Threading;
using System.Threading.Tasks;

public class PaymentWorker : BackgroundService
{
    private readonly ILogger<PaymentWorker> _logger;
    private readonly IPaymentProcessor _paymentProcessor;

    public PaymentWorker(ILogger<PaymentWorker> logger, IPaymentProcessor paymentProcessor)
    {
        _logger = logger;
        _paymentProcessor = paymentProcessor;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            _logger.LogInformation("Iniciando ciclo do Worker...");

            _paymentProcessor.ProcessPayment(100.50m); // Simulando pagamento

            await Task.Delay(5000, stoppingToken); // Executa a cada 5 segundos
        }
    }
}

📌 Passo 6: Configurando a Injeção de Dependência (DI) com Scrutor

Podemos usar a biblioteca Scrutor para simplificar o registro do Decorator.
Primeiro, instalamos a dependência via NuGet:

dotnet add package Scrutor

Agora, configuramos os serviços no Program.cs:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using Scrutor;

class Program
{
    static void Main(string[] args)
    {
        var host = Host.CreateDefaultBuilder(args)
            .ConfigureServices((hostContext, services) =>
            {
                services.AddSingleton<LegacyPaymentService>(); // Serviço legado

                // Registra o Adapter
                services.AddSingleton<PaymentAdapter>(); 
                services.AddSingleton<IPaymentProcessor>(provider => 
                    provider.GetRequiredService<PaymentAdapter>());

                // Adiciona o LoggingDecorator automaticamente com Scrutor
                services.Decorate<IPaymentProcessor, LoggingDecorator>();

                // Registra o Worker Service
                services.AddHostedService<PaymentWorker>(); 
                services.AddLogging(); 
            })
            .Build();

        host.Run();
    }
}

📌 Estrutura de Pastas

Aqui está a estrutura do projeto para manter tudo organizado:

📂 PaymentProcessorApp
│── 📂 Adapters
│ └── PaymentAdapter.cs
│── 📂 Decorators
│ └── LoggingDecorator.cs
│── 📂 Interfaces
│ └── IPaymentProcessor.cs
│── 📂 Services
│ └── LegacyPaymentService.cs
│── 📂 Workers
│ └── PaymentWorker.cs
│── Program.cs
│── PaymentProcessorApp.csproj

🚀 Benefícios dessa Abordagem

✅ Código modular e reutilizável → Podemos adicionar novos IPaymentProcessor ou decorators sem alterar a implementação principal.
✅ Extensibilidade → Podemos criar mais decorators, como um validador ou auditoria.
✅ Baixo acoplamento → Usando DI e Scrutor, evitamos dependências rígidas.
✅ Facilidade de Testes → Podemos testar LoggingDecorator separadamente.

Essa abordagem combina Adapter e Decorator Patterns com Injeção de Dependência, mantendo o código limpo, flexível e escalável.

Se você gostou, deixe um comentário ou compartilhe! 🚀🔥

Adapter Pattern em C# com Injeção de Dependência e Worker Service

Luciano Azevedo — Sun, 02 Feb 2025 20:36:38 +0000

🚀 Aplicando o Adapter Pattern em C# com Injeção de Dependência e Worker Service

📌 Introdução

Ao trabalhar com sistemas legados, é comum encontrar APIs ou serviços que não seguem as interfaces modernas do nosso código. Em vez de modificar diretamente esses sistemas, podemos usar o Adapter Pattern para fazer a integração de forma elegante.

Neste artigo, vou mostrar como implementar o Adapter Pattern em C#, usando Injeção de Dependência (DI) e um Worker Service para simular um processo contínuo.

🎯 O que é o Adapter Pattern?

O Adapter Pattern é um padrão estrutural que permite que objetos com interfaces incompatíveis trabalhem juntos. Ele age como um intermediário, convertendo a interface de uma classe para outra esperada pelo sistema.

📌 Quando usar?

✅ Quando precisamos integrar APIs ou bibliotecas legadas que não podem ser alteradas.
✅ Quando queremos manter um código desacoplado e flexível.
✅ Quando temos diferentes implementações que precisam seguir um mesmo contrato.

🛠️ Implementação

Vamos construir um exemplo onde temos um sistema de pagamentos legados e queremos integrá-lo a um Worker Service que processa pagamentos periodicamente.

🏗️ 1️⃣ Criamos a interface moderna IPaymentProcessor

public interface IPaymentProcessor
{
    void ProcessPayment(decimal amount);
}

🏗️ 2️⃣ Criamos o serviço legado LegacyPaymentService

Este é um serviço que já existe e que queremos reutilizar, mas ele usa uma interface diferente.

public sealed class LegacyPaymentService
{
    public void MakePayment(string amount)
    {
        Console.WriteLine($"Processing payment of {amount} via legacy system.");
    }
}

🏗️ 3️⃣ Criamos o Adapter PaymentAdapter

Aqui adaptamos LegacyPaymentService para seguir a interface IPaymentProcessor.

public sealed class PaymentAdapter : IPaymentProcessor
{
    private readonly LegacyPaymentService _legacyPaymentService;

    public PaymentAdapter(LegacyPaymentService legacyPaymentService)
    {
        _legacyPaymentService = legacyPaymentService;
    }

    public void ProcessPayment(decimal amount)
    {
        string amountString = amount.ToString("F2");
        _legacyPaymentService.MakePayment(amountString);
    }
}

🏗️ 4️⃣ Criamos o Worker Service PaymentWorker

Nosso Worker será responsável por chamar o IPaymentProcessor periodicamente.

using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using System;
using System.Threading;
using System.Threading.Tasks;

public class PaymentWorker : BackgroundService
{
    private readonly ILogger<PaymentWorker> _logger;
    private readonly IPaymentProcessor _paymentProcessor;

    public PaymentWorker(ILogger<PaymentWorker> logger, IPaymentProcessor paymentProcessor)
    {
        _logger = logger;
        _paymentProcessor = paymentProcessor;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            _logger.LogInformation("Iniciando processamento de pagamento...");

            _paymentProcessor.ProcessPayment(100.50m); // Simulando pagamento de R$100,50

            _logger.LogInformation("Pagamento processado com sucesso!");

            await Task.Delay(5000, stoppingToken); // Executa a cada 5 segundos
        }
    }
}

🏗️ 5️⃣ Configuramos a Injeção de Dependência no Host

Agora precisamos configurar os serviços no Host do Worker Service.

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

class Program
{
    static void Main(string[] args)
    {
        var host = Host.CreateDefaultBuilder(args)
            .ConfigureServices((hostContext, services) =>
            {
                services.AddSingleton<LegacyPaymentService>(); // Serviço legado
                services.AddSingleton<IPaymentProcessor, PaymentAdapter>(); // Adapter
                services.AddHostedService<PaymentWorker>(); // Worker Service
                services.AddLogging(); // Logs
            })
            .Build();

        host.Run();
    }
}

✅ O que aprendemos?

✔ Como usar o Adapter Pattern para conectar serviços legados a um código moderno.
✔ Como estruturar Injeção de Dependência (DI) para desacoplar o código.
✔ Como criar um Worker Service que processa tarefas periodicamente.

🚀 Conclusão

O Adapter Pattern é uma solução poderosa para integrar serviços sem alterar o código legado. Combinado com Injeção de Dependência e Worker Services, ele nos permite construir sistemas escaláveis e bem estruturados.

E você? Já usou esse padrão em algum projeto? Deixe um comentário! 🚀

DEV Community: Luciano Azevedo

Consuming RabbitMQ Messages as Background Jobs in .NET with NexJob

1. Setting Up the Trigger

2. Writing the Job Handler

3. What Happens Under the Hood

The 4 Guarantees You Get for Free:

4. What About Publishing? (The Outbox Producer)

Registering the Producer:

Enqueuing Messages via IScheduler:

5. Monitoring in the Dashboard

Summary

Consuming Kafka events as background jobs in .NET with NexJob

What you need

1. A project and packages

2. Write the job

3. Register the Kafka trigger

4. How offsets and retries work

5. Publishing messages back to Kafka (Outbox pattern)

Next steps

Your first background job in .NET with NexJob

Your first background job in .NET with NexJob

What you need

1. A project

2. Register NexJob

3. Write the job

4. Enqueue it

5. Run it

A job that takes input

What happens if the process stops?

Where to go next

🏗️ Aplicando Adapter e Decorator Patterns com Injeção de Dependência no C#

Adapter Pattern em C# com Injeção de Dependência e Worker Service

Enqueuing Messages via `IScheduler`: