DEV Community: Lenerson Velho Nunes

De MassTransit para Wolverine: Uma alternativa moderna, leve e focada em performance

Lenerson Velho Nunes — Thu, 10 Jul 2025 18:39:41 +0000

*Finalizando a série sobre as bibliotecas .NET que deixaram — ou estão deixando — de ser open source e gratuitas, neste artigo apresento uma alternativa ao MassTransit e explico por que ela pode representar uma evolução em termos de arquitetura, simplicidade e performance.

O MassTransit sempre foi uma das opções mais populares no ecossistema .NET para implementar mensageria, comunicação assíncrona e padrões como Publish/Subscribe, Request/Response e Sagas. No entanto, com o anúncio do licenciamento pago nas versões mais recentes, muitos times começaram a buscar alternativas que mantenham boas práticas, mas sem o impacto de novos custos.

Além disso, o MassTransit, por ser uma solução robusta, pode adicionar uma camada extra de complexidade e overhead em cenários onde o foco é performance e simplicidade.

Foi nesse cenário que surgiu a necessidade de explorar o Wolverine — uma biblioteca moderna, open source e com um foco agressivo em alta performance, simplicidade e integração nativa com o .NET.

Por que considerar o Wolverine?

O Wolverine combina mensageria distribuída, transporte in-process e implementação do padrão Mediator, tudo em uma única solução. Ele se destaca por:

Ser gratuito e open source.
Eliminar dependências externas como MediatR.
Oferecer suporte a mensageria in-process e distribuída (RabbitMQ, Azure Service Bus, Amazon SQS, Amazon SNS, Kafka, entre outros).
Focar em alta performance, reduzindo alocações e overhead.
Suportar Sagas e Process Managers com armazenamento de estado.

Comparativo Técnico — Wolverine vs MassTransit

Critério	MassTransit	Wolverine .NET
Licenciamento	Gratuito até a v8; novas versões exigem licença paga.	Gratuito e open source, sem custos para uso comercial.
Complexidade da API	Robusta, rica em recursos, com curva de aprendizado maior.	Enxuta, declarativa e de fácil compreensão.
Mensageria In-Process	Não possui nativamente.	Suporte completo a transporte in-process.
Mensageria Distribuída	RabbitMQ, Azure Service Bus, Amazon SQS, Kafka, etc.	RabbitMQ, Azure Service Bus, Amazon SQS/SNS, Kafka, etc.
Padrão Mediator	Depende de biblioteca externa como MediatR ou Mediator.	Implementa Mediator Pattern de forma nativa.
Sagas e Process Managers	Suporte completo com persistência e timeouts.	Suporte a Sagas e stateful handlers com persistência.
Integração com .NET Core	Alta integração, suporte a DI e middlewares.	Integração nativa com ASP.NET Core e minimal APIs.
Performance e Overhead	Robusto, com overhead perceptível em cenários simples.	Foco agressivo em alta performance, baixo overhead.
Extensibilidade	Suporte a middlewares, interceptadores e customizações.	API enxuta e extensível com simplicidade.

Exemplo Prático: Configuração e Uso Básico do Wolverine

O Wolverine pode ser utilizado tanto para mensageria in-process quanto para comunicação assíncrona distribuída. A seguir, um exemplo simples com envio e consumo de mensagens.

Uso com Transporte In-Process

Ideal para iniciar projetos monolíticos ou aplicações que ainda não precisam de mensageria distribuída.

Instale o pacote:

dotnet add package WolverineFx

Defina a mensagem:

namespace Wolverine.Message;

public sealed record CreateMessage(Guid Id, string Content);

Defina o Handler:

using Wolverine.Message;

public sealed class CreateMessageHandler(ILogger<CreateMessageHandler> logger)
{
    public void Handle(CreateMessage message) =>
        logger.LogInformation("Message is: {message}", message);
}

Configure a Minimal API:

using Wolverine;
using Wolverine.Message;

var builder = WebApplication.CreateBuilder(args);
builder.Host.UseWolverine();
builder.Services.AddOpenApi();

var app = builder.Build();

if (app.Environment.IsDevelopment())
    app.MapOpenApi();

app.UseHttpsRedirection();

app.MapPost("/message", async (CreateMessage request, IMessageBus messageBus) =>
{
    await messageBus.SendAsync(request);
}).WithName("CreateMessage");

app.Run();

A cada POST realizado no endpoint /message, o método bus.SendAsync publica a mensagem no barramento interno de mensagens do Wolverine (em memória). Essa mensagem é imediatamente roteada para o CreateMessageHandler, que a processa de forma síncrona e eficiente, sem necessidade de um broker externo.

Uso com RabbitMQ

Crie dois projetos Console Application: um produtor e um consumidor.

Instale os pacotes em ambos:

dotnet add package WolverineFx
dotnet add package WolverineFx.RabbitMQ

Defina a mensagem:

namespace Wolverine.Message;

public sealed record MessageCreated(Guid Id, string Content, DateTime dateTime);

Produtor:

using Microsoft.Extensions.Hosting;
using Wolverine;
using Wolverine.RabbitMQ;
using Wolverine.RabbitMQ.Producer;
using Wolverine.Message;

using var host = Host.CreateDefaultBuilder()
    .UseWolverine(options =>
    {
        const string exchangeName = "my-messages-exchange";

        options.UseRabbitMq(c => c.HostName = "localhost")
            .DeclareExchange(exchangeName, exchange =>
            {
                exchange.BindQueue("my-message-queue", "exchangeToMyMessages");
            })
            .AutoProvision();

        options.PublishMessage<MessageCreated>().ToRabbitExchange(exchangeName);
        options.Services.AddHostedService<ProducerBackgroundService>();
    }).Build();

await host.RunAsync();

A fila my-message-queue é configurada como o canal de envio no RabbitMQ.

public sealed class ProducerBackgroundService(IServiceProvider sp) : IHostedService
{
    public async Task StartAsync(CancellationToken ct)
    {
        await using var scope = sp.CreateAsyncScope();
        var bus = scope.ServiceProvider.GetRequiredService<IMessageBus>();
        var logger = scope.ServiceProvider.GetRequiredService<ILogger<ProducerBackgroundService>>();

        var count = 0;

        while (!ct.IsCancellationRequested)
        {
            var message = new MessageCreated(Guid.NewGuid(), $"Content {count++}", DateTime.Now);
            logger.LogInformation("Produced message is: {message}", message);
            await bus.SendAsync(message);
            await Task.Delay(TimeSpan.FromSeconds(30), ct);
        }
    }

    public Task StopAsync(CancellationToken ct) => Task.CompletedTask;
}

O método bus.SendAsync publica uma mensagem na fila a cada 30 segundos.

Consumidor:

using Microsoft.Extensions.Hosting;
using Wolverine;
using Wolverine.RabbitMQ;

using var host = Host.CreateDefaultBuilder()
    .UseWolverine(options =>
    {
        options.UseRabbitMq(c => c.HostName = "localhost").AutoProvision();
        options.ListenToRabbitQueue("my-message-queue");
    }).Build();

await host.RunAsync();

A fila my-message-queue é configurada como o canal de recebimento do RabbitMQ.

public sealed class MessageCreatedHandler(ILogger<MessageCreatedHandler> logger)
{
    public void Handle(MessageCreated message) =>
        logger.LogInformation("Message created is: {message}", message);
}

O MessageCreatedHandler consome as mensagens dessa fila, processando cada uma assim que chega.

Para ver o código completo, acesse o repositório no GitHub.

Conclusão

O Wolverine surge como uma alternativa moderna, leve e altamente performática para aplicações .NET orientadas a mensagens.

Além de eliminar a necessidade de licenciamento em cenários corporativos, o Wolverine se destaca por:

Oferecer mensageria in-process e distribuída em uma única solução.
Implementar o padrão Mediator de forma nativa, reduzindo dependências.
Priorizar alta performance, com foco em baixo overhead e simplicidade.
Ser gratuito e open source, sem custos adicionais ou restrições comerciais.

Para equipes que buscam reduzir a complexidade, evitar custos com licenciamento e manter uma arquitetura enxuta e escalável, o Wolverine se mostra uma opção altamente viável — especialmente em projetos que evoluem de monolitos para arquiteturas distribuídas.

🚀 E você, já conhecia o Wolverine?
💬 Está avaliando alternativas ao MassTransit?
Me conta nos comentários e vamos trocar experiências!

Precisa de apoio para decidir o futuro dos seus projetos — manter, evoluir ou começar do zero? Fale com a gente!
Nosso time de especialistas está pronto para ajudar você a enfrentar esses e outros desafios tecnológicos.

Referências

MassTransit

Wolverine

De MediatR para Mediator: uma migração mais leve e performática

Lenerson Velho Nunes — Thu, 15 May 2025 15:16:19 +0000

*Dando continuidade à série sobre bibliotecas .NET que deixaram de ser open source e gratuitas, neste artigo apresento uma alternativa ao MediatR e explico por que ela pode representar uma migração mais leve em termos de estrutura e performance.

Desde que foi anunciado que o MediatR passará a adotar um modelo de licenciamento pago — mesmo que isso ainda leve algum tempo e a versão atual permaneça gratuita — nós, desenvolvedores, começamos a buscar alternativas próximas do que já conhecemos ou, em alguns casos, optamos por implementações próprias, como abordado no artigo anterior sobre o AutoMapper.

Tendo isso em mente, encontrei uma alternativa — especialmente adequada para projetos que precisam ser migrados e para equipes já familiarizadas com o MediatR — que é o Mediator (com “o”). Assim como o anterior, ele implementa o padrão mediator e preserva as mesmas abstrações e recursos, já que foi desenvolvido com base no próprio MediatR.

Isso permite que atualizações em sistemas existentes ocorram de forma muito mais tranquila e rápida, além de facilitar sua adoção em novos contextos, já que a estrutura de implementação praticamente não se altera em relação ao que já estamos habituados a utilizar.

Um ponto especialmente relevante — e que me chamou bastante a atenção — é o foco do Mediator em performance. Isso se deve ao fato de sua implementação utilizar Source Generators, um recurso introduzido no C# 9, em que, diferentemente do MediatR, que se baseia em reflexão para registrar e resolver seus handlers, é gerado código durante o tempo de compilação.

Isso não significa que a abordagem do MediatR seja ruim — muito pelo contrário. A reflexão utilizada por ele é altamente otimizada. No entanto, código gerado e compilado diretamente tende a oferecer desempenho consideravelmente superior em relação a soluções baseadas em reflexão.

Os benchmarks disponíveis na documentação do Mediator evidenciam um ganho significativo de performance em relação ao MediatR.

Migrando do MediatR para o Mediator

A seguir, mostro um exemplo real de migração de um projeto baseado em MediatR para Mediator, destacando o que foi alterado.

1) Removendo o MediatR

Desinstale todas as referências ao pacote MediatR com o seguinte comando:

dotnet remove package MediatR

No projeto de exemplo, esse processo foi realizado em três Class Libraries.

2) Instalando o Mediator

Adicione os pacotes do Mediator em substituição:

dotnet add package Mediator.SourceGenerator --version 3.0.*-*
dotnet add package Mediator.Abstractions --version 3.0.*-*

3) Ajustando os serviços

Altere a classe de configuração de dependências:

// Anterior
// using MediatR;

// Novo
using Mediator;

// Anterior
// services.AddMediator(c => c.RegisterServicesFromAssembly(typeof(Course).GetTypeInfo().Assembly));

// Novo
services.AddMediator((MediatorOptions options) => options.Assemblies = [typeof(Course)]);

4) Atualizando comandos, eventos e handlers

Command:

// Anterior
// using MediatR;

// Novo
using Mediator;

public abstract class CourseCommand : IRequest
{
    // Propriedades e construtor inalterados
}

Event:

// Anterior
// using MediatR;

// Novo
using Mediator;

public sealed class RegisteredCourseEvent : INotification
{
    // Propriedades, construtor e factory method inalterados
}

CommandHandler:

//Anterior
// using MediatR;

//Novo
using Mediator;

public sealed class CourseCommandHandler :
    IRequestHandler<RegisterCourseCommand>,
    IRequestHandler<UpdateCourseCommand>,
    IRequestHandler<RemoveCourseCommand>
{
    // Atributos e construtor inalterados

    //Anterior
    // public async Task<Unit> Handle(RegisterCourseCommand request, CancellationToken cancellationToken)

    // Novo
    public async ValueTask<Unit> Handle(RegisterCourseCommand request, CancellationToken cancellationToken)
    {
        // Lógica de negócio inalterada

        // Anterior
        // return await Unit.Task;

        // Novo
        return await Unit.ValueTask;
    }

   // Anterior
   // public async Task<Unit> Handle(UpdateCourseCommand request, CancellationToken cancellationToken)

    // Novo
    public async ValueTask<Unit> Handle(UpdateCourseCommand request, CancellationToken cancellationToken)
    {
        // Lógica de negócio inalterada

        // Anterior
        // return await Unit.Task;

        // Novo
        return await Unit.ValueTask;
    }

    // Anterior
    // public async Task<Unit> Handle(RemoveCourseCommand request, CancellationToken cancellationToken)

    // Novo
    public async ValueTask<Unit> Handle(RemoveCourseCommand request, CancellationToken cancellationToken)
    {
        // Lógica de negócio inalterada

        // Anterior
        // return await Unit.Task;

        // Novo
        return await Unit.ValueTask;
    }
}

EventHandler:

// Anterior
// using MediatR;

// Novo
using Mediator;

public sealed class CourseEventHandler : INotificationHandler<RegisteredCourseEvent>
{
    // Anterior
    // public async Task Handle(RegisteredCourseEvent notification, CancellationToken cancellationToken)

    // Novo
    public async ValueTask Handle(RegisteredCourseEvent notification, CancellationToken cancellationToken)
    {
        // Exemplo para envio de e-mail quando o cliente se registrar em um curso
        //notification.Emails.ForEach(e => SendMail(e));

        // Anterior
        // await Task.CompletedTask;

        // Novo
        await ValueTask.CompletedTask;
    }
}

CourseAppService


// Anterior
// using MediatR;

// Novo
using Mediator;

public sealed class CourseAppService : ICourseAppService
{
    // Atributos, construtor e métodos inalterados
}

⚠️ Observação: Note que nos Handlers, o retorno dos métodos Handle mudou de Task para ValueTask.

Neste post, não vamos entrar em detalhes sobre o funcionamento do ValueTask, mas, de forma resumida, trata-se de uma struct que pode evitar alocação de memória heap, reduzindo a pressão sobre o Garbage Collector e sendo mais eficiente em cenários onde a operação assíncrona é concluída rapidamente.

Você pode ver as alterações e o projeto de exemplo completo no GitHub.

Conclusão

O Mediator se mostra uma alternativa viável, leve e altamente compatível com a abordagem que o MediatR já entregava.

Sua estrutura familiar, aliada ao uso de Source Generators, torna a migração simples e vantajosa em termos de performance e manutenção. Para quem está reavaliando o futuro da stack de desenvolvimento .NET, vale a pena considerar o Mediator.

E você, já migrou ou ainda está avaliando como fazer a transição? Compartilhe sua experiência nos comentários.

Até o próximo artigo!

Referências

Ainda precisamos do AutoMapper em projetos .NET?

Lenerson Velho Nunes — Wed, 23 Apr 2025 14:17:14 +0000

*Este é o terceiro artigo da série sobre bibliotecas amplamente utilizadas no ecossistema .NET que deixaram — ou estão deixando — de ser open source e gratuitas.

Como vimos no primeiro artigo dessa série, em breve o AutoMapper deixará de ser gratuito. Diante dessa mudança, muitos times estão repensando sua dependência dessa biblioteca. Mas será que ainda precisamos dela?

Confesso que já faz um bom tempo desde a última vez que usei AutoMapper em um projeto. A maioria dos sistemas em que tenho trabalhado são grandes, com alta complexidade e demanda, e nesse tipo de cenário o AutoMapper costuma trazer dois principais entraves:

1) Performance

O AutoMapper funciona com base em reflexão, ou seja, opera em tempo de execução. Isso significa que, para acessar um tipo, método, propriedade ou campo, o CLR precisa realizar algumas etapas dinamicamente:

Carregamento de Metadados: O CLR carrega os metadados do assembly, do tipo e do membro que está sendo acessado. Esses metadados descrevem a estrutura do código, mas seu acesso é mais custoso do que operações diretamente na memória executável.
Verificação de Segurança e Acesso: O CLR verifica as permissões de segurança e a acessibilidade do membro, garantindo que a operação seja permitida.
Resolução Dinâmica: O CLR identifica o membro com base no nome (string) e na assinatura (no caso de métodos), o que exige uma busca nos metadados.
Invocação Dinâmica: Para métodos, o CLR precisa configurar a pilha de execução e fazer a chamada de forma dinâmica — algo consideravelmente mais custoso do que uma chamada direta.

Esse processo todo, apesar de poderoso e flexível, pode impactar significativamente a performance em cenários de alta carga ou com grande volume de operações de mapeamento.

2) Sobrecarga Estrutural

À medida que um projeto cresce, as entidades de domínio se tornam cada vez mais complexas, com diversas relações e dependências. Rapidamente, os DTOs deixam de refletir fielmente essas entidades, exigindo um número maior de classes de mapeamento e customização — que também tendem a se tornar mais complexas.

O resultado é um aumento considerável de código implícito, o que dificulta a leitura, manutenção e, principalmente, o processo de depuração.

Adotando uma abordagem mais leve e eficiente

Diante dos impactos de performance e da sobrecarga estrutural, uma alternativa que tenho adotado com bons resultados é abrir mão do AutoMapper e realizar os mapeamentos manualmente com o auxílio de métodos simples dentro da classe DTO. Embora isso exija um pouco mais de código explícito, o ganho em clareza, controle e facilidade de manutenção compensa — especialmente em projetos mais robustos.

Vamos a um exemplo prático:

Considere as seguintes classes, que representam entidades do domínio de um sistema de pedidos:

public class ProdutoEntity
{
    public int Id { get; set; }
    public string Descricao { get; set; }
}

public class PedidoEntity
{
    public int Id { get; init; }
    public DateTime DataPedido { get; init; }
    public ICollection<ItemPedidoEntity> Itens { get; init; }
    public decimal ValorTotal { get; init; }
}

public class ItemPedidoEntity
{
    public int Id { get; init; }
    public int PedidoId { get; init; }
    public PedidoEntity Pedido { get; init; }
    public int ProdutoId { get; init; }
    public ProdutoEntity Produto { get; init; }
    public int Quantidade { get; init; }
    public decimal PrecoUnitario { get; init; }
}

E os seguintes DTOs:

public sealed class PedidoDto
{
    public int Id { get; init; }
    public DateTime DataPedido { get; init; }
    public ICollection<ItemPedidoDto> Itens { get; init; }
    public decimal ValorTotal { get; init; }
}

public sealed class ItemPedidoDto
{
    public int Id { get; init; }
    public required string DescricaoProduto { get; init; }
    public int Quantidade { get; init; }
    public decimal PrecoUnitario { get; init; }

    public decimal Subtotal => Quantidade * PrecoUnitario;
}

Vamos adicionar dois métodos à classe ItemPedidoDto:

/// <summary>
/// Converte uma coleção de entidades de itens de pedido em uma coleção de DTOs.
/// </summary>
public static ICollection<ItemPedidoDto> MapFromItemPedidoEntityCollection(
    ICollection<ItemPedidoEntity> itensPedido
)
{
    var resultado = new List<ItemPedidoDto>();

    foreach (var itemPedidoEntity in itensPedido)
    {
        resultado.Add(
            new ItemPedidoDto
            {
                Id = itemPedidoEntity.Id,
                DescricaoProduto = itemPedidoEntity.Produto.Descricao,
                Quantidade = itemPedidoEntity.Quantidade,
                PrecoUnitario = itemPedidoEntity.PrecoUnitario
            }
        );
    }

    return resultado;
}

/// <summary>
/// Converte uma coleção de DTOs de itens de pedido em uma coleção de entidades.
/// </summary>
public static ICollection<ItemPedidoEntity> MapToItemPedidoEntityCollection(
    ICollection<ItemPedidoDto> itensPedido
)
{
    var resultado = new List<ItemPedidoEntity>();

    foreach (var itemPedidoDto in itensPedido)
    {
        resultado.Add(new ItemPedidoEntity
        {
            Id = itemPedidoDto.Id,
            Quantidade = itemPedidoDto.Quantidade,
            PrecoUnitario = itemPedidoDto.PrecoUnitario
        });
    }

    return resultado;
}

E mais dois métodos na classe PedidoDto, utilizando os anteriores:

/// <summary>
/// Converte uma entidade de pedido em seu respectivo DTO.
/// </summary>
public static PedidoDto MapFromPedidoEntity(PedidoEntity pedido) =>
    new()
    {
        Id = pedido.Id,
        DataPedido = pedido.DataPedido,
        Itens = ItemPedidoDto.MapFromItemPedidoEntityCollection(pedido.Itens),
        ValorTotal = pedido.ValorTotal
    };

/// <summary>
/// Converte uma instância de DTO de pedido em sua respectiva entidade.
/// </summary>
public PedidoEntity MapToPedidoEntity() =>
    new()
    {
        Id = Id,
        DataPedido = DataPedido,
        Itens = ItemPedidoDto.MapToItemPedidoEntityCollection(Itens),
        ValorTotal = ValorTotal
    };

Essa abordagem pode parecer mais "verbosa", mas o ganho em previsibilidade e clareza compensa. Cada transformação está explícita, facilitando a manutenção, testes e principalmente a depuração — algo crítico em projetos maiores. No fim das contas, escrever o mapeamento à mão pode parecer um pequeno esforço extra, mas é um investimento que retorna em produtividade a longo prazo.

Conclusão

Em contextos menores ou com mapeamentos triviais, o AutoMapper continua sendo uma ferramenta válida. Porém, em projetos mais complexos, os custos de performance e manutenção já eram consideráveis — e agora, com a transição para um modelo pago, a decisão de evitá-lo ganha ainda mais força.

Adotar uma abordagem manual, centrando os mapeamentos nos próprios DTOs, tem se mostrado mais eficiente em termos de clareza, controle e colaboração em equipe. É um caminho mais explícito e menos mágico — e que, no fim das contas, pode resultar em mais produtividade e menos dor de cabeça.

E você, ainda usa AutoMapper nos seus projetos? Já sentiu esses impactos ou encontrou outra solução mais equilibrada? Me conte nos comentários.

Até o próximo artigo!

Referências

AutoMapper
Reflection in .NET

Substituindo FluentAssertions por Shouldly em Projetos .NET

Lenerson Velho Nunes — Wed, 16 Apr 2025 13:29:17 +0000

*Este é o segundo artigo da série sobre bibliotecas amplamente utilizadas no ecossistema .NET que deixaram — ou estão deixando — de ser open source. Neste artigo, vamos tratar especificamente da substituição do FluentAssertions pelo Shouldly.

Como vimos no artigo anterior, a partir da versão 8, a biblioteca FluentAssertions passou a exigir uma licença paga no valor de US$ 130 por usuário para aplicações de uso comercial. Isso pode representar um obstáculo para muitos desenvolvedores e empresas, especialmente considerando o custo em relação ao que a biblioteca oferece. Apesar de melhorar a legibilidade na escrita de testes unitários, seu uso não envolve nada tão avançado que justifique esse investimento — ainda mais quando existe uma alternativa bastante semelhante e gratuita.

Estou falando do Shouldly, que além de oferecer funcionalidades muito próximas às do FluentAssertions, ainda possui a vantagem de exibir mensagens ainda mais claras e informativas quando um teste falha — o que pode fazer bastante diferença no dia a dia do desenvolvimento.

Instalando o Shouldly

Para começar a usar o Shouldly, instale o pacote NuGet no seu projeto. Você pode fazer isso copiando e colando o seguinte comando no Console do Gerenciador de Pacotes do Visual Studio:

Install-Package Shouldly

Como alternativa, se você estiver usando o .NET Core, você pode instalar o Shouldly por meio da interface de linha de comando com o seguinte comando:

dotnet add package Shouldly

Substituindo Asserções:

Vamos dar uma olhada em algumas asserções comuns e ver como elas ficam com o Shouldly em comparação ao FluentAssertions:

Asserção de Igualdade

// FluentAssertions
result.Should().Be(10);

// Exemplo de mensagem de falha:
Expected result to be 10, but found 11 (difference of 1).

// Shouldly
result.ShouldBe(10);

// Exemplo de mensagem de falha:
Shouldly.ShouldAssertException : result
    should be
10
    but was
11

Asserção de Strings

// FluentAssertions
result.Should().NotBeNullOrEmpty();

// Shouldly
result.ShouldNotBeNullOrEmpty();

Asserção de Coleções

// FluentAssertions
result.Should().Contain(item);

// Shouldly
result.ShouldContain(item);

Asserção de Dicionários

// FluentAssertions
result.Should().ContainKey("Key");

// Shouldly
result.ShouldContainKey("Key");

Asserção de Exceções

// FluentAssertions
Action action = () => calculator.Divide(10, 0);
action.Should().Throw<DivideByZeroException>();

// Shouldly
Should.Throw<DivideByZeroException>(() => calculator.Divide(10, 0));

Conclusão

A migração do FluentAssertions para um modelo pago levanta uma discussão importante sobre dependências em projetos .NET. Felizmente, o Shouldly surge como uma alternativa sólida, gratuita e de fácil adoção, oferecendo uma experiência semelhante e até superior em alguns aspectos, como nas mensagens de falha.

E você, já conhecia o Shouldly? O que achou da comparação? Me conta nos comentários — vamos conversar!

Até o próximo artigo!

Referências

FluentAssertions

Shouldly

Bibliotecas Populares do .NET Deixam de Ser Gratuitas em 2025

Lenerson Velho Nunes — Wed, 09 Apr 2025 14:58:54 +0000

*Este é o primeiro artigo de uma série na qual vamos explorar outras alternativas open source que podem ser adotadas como substitutas para as bibliotecas mencionadas.

Nos primeiros meses de 2025, desenvolvedores .NET têm sido surpreendidos por anúncios de mudanças significativas em bibliotecas open source populares, que estão deixando de ser totalmente gratuitas. Somente na última semana, três bibliotecas amplamente utilizadas — AutoMapper, MediatR e MassTransit — anunciaram novos modelos de licenciamento. Antes delas, em 15 de janeiro, foi a vez do FluentAssertions, o que vêm gerando desconforto e preocupação entre desenvolvedores e empresas que utilizam essas ferramentas.

FluentAssertions

A Xceed, uma empresa de componentes .NET, anunciou uma "parceria estratégica com a Fluent Assertions". A empresa disse que integraria a biblioteca em seu conjunto de ferramentas de desenvolvimento “enquanto honraria os princípios de código aberto”. De acordo com a publicação, isso significa continuar a honrar licenças gratuitas para “projetos de código aberto e não comerciais”. Anteriormente, a licença Apache 2.0 permitia o uso “sem custos, livre de royalties” em projetos comerciais e não comerciais, sejam de código aberto ou não.

A partir de agora, o uso em projetos comerciais só será permitido mediante a aquisição de uma licença no valor de US$ 130 por desenvolvedor. 😧

AutoMapper e MediatR

O anúncio foi feito por Jimmy Bogard, criador de ambas as bibliotecas:

Para garantir a sustentabilidade de longo prazo dos meus projetos de
OSS, estarei comercializando o AutoMapper e o MediatR.

Ainda segundo Jimmy, os projetos nasceram enquanto ele trabalhava na empresa Headspring, onde atuou por 12 anos e recebia incentivo e financiamento para desenvolvê-los. No entanto, após sair da empresa em 2020 e se tornar consultor independente, seu tempo e contribuição para os projetos diminuíram drasticamente, o que o impediu de levá-los adiante como gostaria.

Como ele mesmo destacou em seu anúncio sobre o futuro, ainda não há um modelo de comercialização definido — e, por enquanto, nada mudará.

MassTransit

Conforme o anúncio publicado no site do MassTransit, a partir da versão 9 a biblioteca passará a ser um produto comercial.

Essa decisão visa garantir a sustentabilidade a longo prazo, promover
inovações contínuas e oferecer suporte de nível empresarial.

Entretanto, a versão 8 permanecerá open-source e disponível para a comunidade, com atualizações de segurança e correções críticas sendo fornecidas durante um período de transição.

A meta de custo estabelecida para quem quiser adquirir a licença para pequenas e médias empresas é de US$ 400/mês ou US$ 4.000/ano. Já pra grandes organizações é de US$ 1.200/mês ou US$ 12.000/ano.

Conclusão

As mudanças no modelo de licenciamento de bibliotecas amplamente utilizadas no ecossistema .NET sinalizam uma transformação importante no equilíbrio entre o open source gratuito e a sustentabilidade de longo prazo dos projetos. Embora compreensíveis do ponto de vista dos mantenedores — que buscam viabilidade financeira para continuar inovando — essas decisões impactam diretamente empresas e desenvolvedores que dependem dessas ferramentas no dia a dia. O momento agora é de reflexão, reavaliação de dependências e, acima de tudo, de adaptação.

E você, utiliza alguma dessas bibliotecas? O que acha dessas mudanças? Me conte suas experiências e opiniões nos comentários.

Referências

FluentAssertions License Change

AutoMapper and MediatR Going Commercial

Announcing MassTransit v9