Forem: William Santos

Performance: Structs e Cópias (Defensivas)

William Santos — Tue, 27 Jan 2026 12:28:02 +0000

Olá!

Este é mais um post da seção Performance e vamos falar sobre uma armadilha invisível no uso de structs em C#: as cópias defensivas.

Vamos lá!

Structs: Por quê?

Vamos recapitular: structs são uma escolha excelente para em cenários onde alocação de memória é uma questão crítica. Por existirem apenas na stack, tendo portanto uma existência efêmera e não sujeita à ação do Garbage Collector, seu uso afeta positivamente o desempenho de uma aplicação, efeito que pode ser constatado no caminho crítico da mesma via profile, ou via benchmarks em ambiente de desenvolvimento, quando avaliado diante de classes.

Mas nem tudo são flores!

Ainda que sejam uma alternativa ao uso de classes e tenham por principal característica a evitação da alocação de memória no heap, existe uma armadilha oculta: as cópias (defensivas).

Cópias: o fundamental

Quando uma struct é passada como parâmetro para um método, dada sua natureza de value type, a passagem acontece por valor, ou seja, uma cópia da struct em questão é gerada dentro do método, o que impede naturalmente que a struct original seja modificada, já que a cópia não é um ponteiro pra ela e encerra seu ciclo de vida ao final do método no qual foi recebida.

O Modificador in

Para permitir a passagem de structs como parâmetros por referência, surgiu o modificador in, o que impede que uma cópia da struct seja criada mas que, ao mesmo tempo, cria um risco: mudança implícita de estado.

Por ser passada por referência, qualquer alteração no estado interno da struct perdurará para além do método invocado, tornando a instância da struct vulnerável à mudanças indesejadas, ainda que o modificador in crie um contexto readonly que não permita a alteração explícita do estado da struct.

Cópias defensivas, uma (aparente) solução

Cópias defensivas são uma forma do compilador (Roslyn) evitar que sua struct sofra mudanças indesejadas quando passadas como parâmetros in, o que aumenta a segurança da aplicação contra efeitos colaterais. Mas, como bem sabemos, segurança sempre custará performance e é exatamente o que acontece neste caso.

Um pequeno exemplo

Aqui temos uma struct chamada Square que representa um quadrado. Um quadrado tem quatro lados iguais, portanto apenas o tamanho de um lado precisa ser conhecido. Vejamos:

public struct Square
{
    public double Side { get; init; }

    public double Area => Side * Side;
}

Repare que esta struct é imutável, ou seja, suas propriedades não podem ser modificadas durante um dado processamento. O problema é que o compilador não sabe se há alguma mudança de estado acionada quando a propriedade Area é invocada e, por isso, cria uma cópia defensiva sempre que encontra uma invocação a este método.

Span<Square> squares = stackalloc Square[1_000];
for(int i = 0, i < squares.Lenght; i++)
{
    squares[i] = new Square { Side = i };
}

var panel = new Panel();
panel.Render(squares); //Renderiza os quadrados via propriedade `Area`.

Adivinhe o que acontece aqui? Se você respondeu que mil cópias defensivas serão criadas a partir do array de Point, acertou na mosca!

Mas, William, mil cópias?!

Aqui está o pulo do gato: cada vez que uma propriedade é utilizada, o compilador cria uma cópia da sua struct toda pra garantir que aquela propriedade não afetará seu estado interno. Percebe o impacto potencial que estas operações geram sobre a performance?

Readonly ao resgate!

Felizmente existe uma forma de lidar com esse problema sem prejuízo da performance, o modificador readonly. Este modificador indica ao compilador que sua struct é imutável, o que garante que não haverá mudança de estado quando a struct for manipulada por um dado método.

O modificador readonly pode ser aplicado em duas dimensões: a struct inteira ou em certas propriedades. Vejamos:

public readonly struct Square
{
    public double Side { get; init; }

    public double Area => Side * Side;
}

Com o modificador aplicado à struct toda, o compilador entender que não há a possibilidade de mudança de estado quando a instância tiver suas propriedades invocadas. Isso faz com que nenhuma cópia defensiva seja criada.

public struct Square
{
    public readonly double Side { get; init; }

    public double Area => Side * Side
}

Com o modificador aplicado apenas a Side o compilador entenderá que a propriedade Area oferece o risco de mudança no estado interno, o que implicará uma cópia defensiva. Entretanto, o mesmo não acontecerá com a propriedade Side.

Performance: medindo o impacto

Abaixo temos uma demonstração do prejuízo à performance por força das cópias defensivas. Vejamos:

Aqui fica claro que, com structs grandes no caminho crítico da aplicação, sem o devido cuidado, as cópias defensivas oferecem um prejuízo perceptível, dado que o mesmo é mensurável em benchmark com dados fictícios.

Conclusão

Conhecer as características internas do compilador é muito útil para pensar sobre como desenhar suas structs e utilizá-las. Este é um caso onde seria simplesmente impossível considerar que suas structs são a causa do problema sem esse conhecimento.

Como sempre, o código do benchmark está disponível no GitHub para te permitir testar e modificar à vontade.

Gostou? Me deixe saber pelo indicadores. Caso tenha alguma dúvida, deixe um comentário ou me procure nas redes sociais. Será um prazer te responder.

Muito obrigado por ler até aqui, e até a próxima!

Coopera Sharp - Chamadas em Sequência

William Santos — Tue, 30 Sep 2025 18:11:45 +0000

Olá!

Este é mais um post da seção CooperaSharp e, desta vez, vamos falar um pouco sobre paralelismo e desempenho.

Vamos lá!

O Problema

O desafio propõe a melhoria de um conjunto de chamadas a uma API para a obtenção de certos dados.

O código do problema está replicado abaixo:

public class IntegradorService
{
    private readonly IApiClienteA _clienteA;
    private readonly IApiClienteB _clienteB;
    private readonly IApiClienteC _clienteC;

    public IntegradorService(
        IApiClienteA clienteA,
        IApiClienteB clienteB,
        IApiClienteC clienteC)
    {
        _clienteA = clienteA;
        _clienteB = clienteB;
        _clienteC = clienteC;
    }

    public async Task<List<Dado>> ObterDados()
    {
        var dados = new List<Dado>();

        var dadosA = await _clienteA.BuscarDados(); // chamada pode demorar
        dados.AddRange(dadosA);

        var dadosB = await _clienteB.BuscarDados(); // chamada pode falhar
        dados.AddRange(dadosB);

        var dadosC = await _clienteC.BuscarDados(); // chamada pode ser lenta
        dados.AddRange(dadosC);

        return dados;
    }
}

Repare no seguinte: o código acima faz uma chamada para uma dada API, obtém seu resultado, adiciona-o a uma lista e faz a chamada seguinte.

Ou seja, o tempo total da execução do método ObterDados vai ser igual à soma do tempo de execução de cada chamada externa. Portanto, se cada chamada levar 1s para ser executada, teremos 3s de tempo total de execução.

Ruim. Certo?

Há mais um detalhe: o código acima é tremendamente otimista! Se alguma exceção ocorrer no meio do caminho ela não apenas não é tratada como é lançada para o método chamador, o que comprometeria todo o processo de obtenção dos dados.

A Solução: Paralelismo!

Algo que podemos fazer em caso semelhante é paralelizar as chamadas às API. Para fazer isso existem duas opções, que exploraremos abaixo:

`Task.WhenAll`

A forma mais simples de fazer diversas chamadas e aguardar sua execução é criando novas threads, uma para cada chamada, unindo-as ao final de suas respectivas execuções para extrair o resultado desejado.

Para isso, vamos transformar as chamadas em Task e realizar todas as chamadas simultaneamente, desta forma:

(...)
var requests = new Task<IEnumerable<WeatherForecast>>[] { serverErrorClient.GetWeatherForecasts(),
                                                          serverSlowClient.GetWeatherForecasts(),
                                                          serverTimeoutClient.GetWeatherForecasts() };

try
{
    var results = await Task.WhenAll(requests);
    var data = results.SelectMany(i => i);

    return Ok(new { Data = data });
}
catch (AggregateException ex)
{
    //Handle inner exceptions on ex
    foreach (exception in ex.InnerExceptions)
    (...)
}
(...)

Repare que acima criamos um array de tasks para abrigar as chamadas e que, para obter seus resultados invocamos o método Task.WhenAll(...).

Mas o que este método faz?

A ideia é que, a partir de uma lista de tarefas, aqui representada pelo nosso array, as mesmas sejam chamadas em paralelo, limitando o tempo de espera por aquela que mais demorar. Esse método também é interessante porque, caso haja exceções lançadas pelas tasks as mesmas serão agregadas em um tipo chamado AggregateException, integrando sua propriedade InnerExceptions. Desta forma é possível registrá-las em log ou manipulá-las, decidindo como o fluxo seguirá.

`Parallel.ForEachAsync`

Existe uma outra forma de obter nossos dados fazendo chamadas em paralelo para as API, o Parallel.ForEachAsync. O código seria o seguinte, nos baseando no código acima:

(...)
var requests = new Task<IEnumerable<WeatherForecast>>[] { serverErrorClient.GetWeatherForecasts(),
                                                          serverSlowClient.GetWeatherForecasts(),
                                                          serverTimeoutClient.GetWeatherForecasts() };

try
{
    ConcurrentBag<IEnumerable<WeatherForecast>> results = [];
    var cts = new CancellationTokenSource();

    await Parallel.ForEachAsync(requests, 
                                new ParallelOptions 
                                { 
                                    MaxDegreeOfParallelism = requests.Lenght,
                                    CancellationToken = cts.Token;
                                },
                                async (request, ct) => 
                                {
                                    ct.ThrowIfCancellationRequested();

                                    var result = await request;
                                    results.Add(result);
                                }).WithAggregateException();

    var data = results.SelectMany(i => i);

    return Ok(new { Elapsed = stopwatch.ElapsedMilliseconds, Data = data });
}
catch (Exception ex)
{
    //Handle ex

    return StatusCode(StatusCodes.Status500InternalServerError);
}
(...)

Repare que aqui temos um capacidade adicional em relação ao Task.WhenAll, que é a possibilidade de estabelecer o número máximo de cores que serão usados, em vez de threads do threadpool, via ParallelOptions { MaxDegreeOfParallelism = requests.Lengh }. O tamanho da nossa lista de requisições não foi informado à toa, ele indica exatamente o número de cores -- repare, cores, não threads! -- que esperamos abrir, solicitadas para tornar as chamadas possíveis.

Ao final de cada requisição adicionaremos o resultado a uma ConcurrentBag, uma coleção threadsafe que armazenará todos os resultados.

Perceba que o comportamento é um tanto diferente to Task.WhenAll. Enquanto este aguarda a execução de todas as tasks para retornar o resultado de seu processamento, o Parallel.ForEachAsync executa a função recebida como parâmetro tão logo uma tarefa seja executada. Ainda assim, a instrução seguinte ao Parallel.ForEachAsync será executada apenas quando todas as tarefas forem concluídas.

Uma outra diferença está na opção WithAggregateException. Enquanto para o Task.WhenAll a lança uma AggregateException por padrão, o Parallel.ForEachAsync precisa ser informado. Não informar vai fazer com que a primeira exceção ocorrida no processamento paralelo seja lançada e o fluxo seja interrompido.

Qual opção usar?

A recomendação é que o Task.WhenAll seja utilizado como primeira escolha sempre que possível. É um mecanismo suficiente para a maioria dos casos e uma solução pouco verbosa.
Já o Parallel.ForEachAsync é uma escolha para quando houver precupação com o controle do uso de recursos ou houver cores disponíveis para executar as tarefas em paralelo, o que é mais performático que alternar entre threads em um mesmo core, sendo uma solução mais completa e um tanto mais performática, ainda que ao custo de maior verbosidade.

Conclusão

Processamento paralelo é um recurso muito interessante para casos como o do desafio, onde é importante processar diversas tarefas no menor tempo possível.

É uma bela alternativa para utlizar melhor certos recursos computacionais, como o threadpool e os cores do processador, de modo a aumentar o desempenho de sua aplicação.

Gostou? Me deixe saber pelos indicadores ou por minhas redes sociais.

Restou alguma dúvida? Fique à vontade para deixá-la nos comentários.

Muito obrigado por ler até aqui, e até a próxima!

Coopera Sharp - Dependency Explosion

William Santos — Mon, 08 Sep 2025 15:21:45 +0000

Olá!

Este é mais um post da seção CooperaSharp e, desta vez, vamos examinar o desafio sobre explosão de dependências.

Vamos lá!

O Problema

Como é possível ver neste post temos um serviço com diversas dependências injetadas, o que cria o que chamamos de explosão de dependências no construtor (constructor dependency explosion em inglês).

Este serviço executa uma série de passos para tornar possível a criação de um pedido.

Esta abordagem é ruim porque, além de já conter inúmeras dependências, ainda pode adicionar mais caso o processo de torne maior, o que levaria a uma explosão ainda maior, tornando o construtor quase um container de dependências.

Aqui o trecho do código ruim:

public class PedidoService
{
    private readonly IClienteRepository _clienteRepository;
    private readonly IPedidoRepository _pedidoRepository;
    private readonly IEstoqueService _estoqueService;
    private readonly IPagamentoService _pagamentoService;
    private readonly IEmailService _emailService;
    private readonly INotificacaoService _notificacaoService;
    private readonly ILogger _logger;
    private readonly IFreteService _freteService;
    private readonly IMapper _mapper;
    private readonly IAuditoriaService _auditoriaService;

    public PedidoService(
        IClienteRepository clienteRepository,
        IPedidoRepository pedidoRepository,
        IEstoqueService estoqueService,
        IPagamentoService pagamentoService,
        IEmailService emailService,
        INotificacaoService notificacaoService,
        ILogger logger,
        IFreteService freteService,
        IMapper mapper,
        IAuditoriaService auditoriaService)
    {
        _clienteRepository = clienteRepository;
        _pedidoRepository = pedidoRepository;
        _estoqueService = estoqueService;
        _pagamentoService = pagamentoService;
        _emailService = emailService;
        _notificacaoService = notificacaoService;
        _logger = logger;
        _freteService = freteService;
        _mapper = mapper;
        _auditoriaService = auditoriaService;
    }

    public void ProcessarPedido(PedidoDto dto)
    {
        var cliente = _clienteRepository.ObterPorId(dto.ClienteId);

        if (cliente == null)
        {
            _logger.Log("Cliente não encontrado");
            return;
        }

        var pedido = _mapper.Map<Pedido>(dto);

        _estoqueService.ReservarItens(pedido.Itens);

        var valorFrete = _freteService.CalcularFrete(dto.EnderecoEntrega);
        pedido.AdicionarFrete(valorFrete);

        var pagamentoOk = _pagamentoService.Processar(pedido);

        if (!pagamentoOk)
        {
            _notificacaoService.Enviar("Falha no pagamento");
            return;
        }

        _pedidoRepository.Salvar(pedido);

        _emailService.EnviarConfirmacao(cliente.Email);
        _auditoriaService.Registrar("Pedido criado", pedido.Id.ToString());
    }
}

Uma Solução Ingênua

Uma das soluções que pode vir à mente neste momento é a de trabalhar com eventos e deixar cada handler se prontificar a resolver uma parte do processo, fazendo com que o PedidoService cuide apenas da persistência do pedido.

Seria uma solução interessante se não fosse por um detalhe: repare neste trecho:

_estoqueService.ReservarItens(pedido.Itens);

var valorFrete = _freteService.CalcularFrete(dto.EnderecoEntrega);
pedido.AdicionarFrete(valorFrete);

O que acontece se houver uma exceção no serviço de frete? Pois é! O o estoque permanece com os itens reservados ainda que o processo no geral falhe. Isso leva a uma inconsistência no estado da aplicação, podendo impedir que outro pedido seja feito por falta de estoque.

Portanto, precisamos pensar numa forma de tornar possível que ações compensatórias como a liberação dos itens seja possível. E aí entra a solução que encontrei para o desafio.

Minha Solução (Elegante?)

Se pensarmos bem, este processo todo é uma transação. Se um passo dela falhar, todas devem falhar, executando um rollback e revertendo a mudança de estado que eventualmente tenha provocado. Então entra em cena um mecanismo de transação em cadeia, inspirado no pattern Chain of Responsibility sobre o qual falo neste post.

Vamos conhecer o código!

Em primeiro lugar, precisamos ser capazes de descrever os passos da nossa transação e, para isso, foram criados os TransactionSteps, como podemos ver abaixo:

public interface ITransactionStep<TInput> where TInput : notnull
{
    Result<Error> Execute(ref TInput input);
    Result<Error> Rollback(Result<Error> error);
}

public abstract class TransactionStepBase<TInput>(ITransactionStep<TInput>? next) : ITransactionStep<TInput> where TInput : notnull
{
    public Result<Error> Execute(ref TInput input)
    {
        var result = ExecuteInternal(ref input);
        if(result && next is not null)
            return next.Execute(ref input);

        if(result && next is null)
            return result;        

        return Rollback(result);
    }

    protected abstract Result<Error> ExecuteInternal(ref TInput input);
    public abstract Result<Error> Rollback(Result<Error> error);
}

Aqui temos uma interface que vai demarcar a anatomia de um passo transacional e, também, uma classe abstrata que deverá ser implementada por cada passo.

Repare que cada passo da transação, tal qual na cadeia de responsabilidades, recebe uma referência para o passo seguinte. A diferença está no método Rollback, que será invocado caso hava um resultado negativo do passo implementação.

Há, também, uma verificação do próximo passo a fim de saber se alcançamos o fim da cadeia.

Agora vamos ver a implementação de um dos passos, o de verificação da existência de um cliente:

public sealed class CustomerValidationStep(CustomerDataAccess customerDataAccess,
                                           OrderStockReservationStep next) : TransactionStepBase<OrderSubmissionBag>(next)
{
    protected override Result<Error> ExecuteInternal(ref OrderSubmissionBag input)
    {
        try
        {
            var customer = customerDataAccess.GetById(input.Request.CustomerId);
            if (customer)
            {
                input.Customer = customer.Get();
                return Result<Error>.Ok();
            }

            return Result<Error>.Error(new Error($"Customer with id {input.Request.CustomerId} not found"));
        }
        catch(Exception ex)
        {
            return Rollback(new Error(ex.Message));
        }
    }

    public override Result<Error> Rollback (Result<Error> error) =>
        error;
}

Repare que aqui temos três possíveis desfechos para a execução deste passo:

O cliente existe e é incluído em uma OrderSubmissionBag que contém uma referência para a requisição recebida pelo servidor, uma para o cliente e outra para o pedido. Neste desfecho o passo seguinte é executado, o OrderStockReservationStep, responsável por reservar os itens do pedido no estoque.
O cliente não existe e é retornado um erro indicando que o Id informado não foi encontrado.
Há uma exceção em algum ponto do fluxo e o método Rollback é acionado. Neste caso, por tratar-se de uma consulta, não há a necessidade de reverter o estado da aplicação, portanto apenas um erro será retornado, interrompendo a execução da cadeia transacional.

Para iniciar a execução destes passos, é necessário um transactor, que funciona apenas como um iniciador do processo.
Veja o código abaixo:

public sealed class OrderSubmissionTransactor(CustomerValidationStep step)
{
    public Result<Error> Process(OrderSubmissionBag bag) =>
        step.Execute(ref bag);
}

Com isso, como pode ser visto no repositório da solução, todos os passos da transação podem ser executados em sequência e novos podem ser encadeados, injetando apenas a dependência do Transactor no Controller, como segue:

[Route("api/[controller]")]
[ApiController]
public class SubmitOrderController(OrderSubmissionTransactor transactor) : ControllerBase
{
    [HttpPost]
    public IActionResult SubmitOrder([FromBody] OrderSubmissionRequest request)
    {
        var result = transactor.Process(new OrderSubmissionBag { Request = request, Customer = null, Order = null });

        return result 
                ? Ok()
                : StatusCode(500, "It was not possible to submit your order. Try again later.");
    }
}

Conclusão

Evitar a explosão de dependências é interessante para manter o código legível e, também, evitar o que alguns chamam de God Classes ou Megazords, classes que respondem por muitas atividades e cuja legibilidade geralmente é baixa, assim como é sua testabilidade - imagine criar e injetar 10 instâncias reais para testar esta classe, ou pior, utilizar mocks para isso!

Com a solução que proponho, cada passo do processo está autocontido, portanto coeso, não tem conhecimento dos demais, exceto pelo passo imediatamente seguinte, eliminamos a explosão de dependências e, também, mantemos a consistência do estado da aplicação.

Aparentemente uma vitória!

Gostou? Me deixe saber pelos indicadores ou por minhas redes sociais.

Muito obrigado por ler até aqui, e até o próximo post!

Coopera Sharp - Otimização de Query

William Santos — Mon, 25 Aug 2025 12:05:05 +0000

Olá!

Este é um post da seção Coopera Sharp, uma iniciativa do colega Yan Justino que propõe desafios no LinkedIn baseados em códigos com más práticas.

Normalmente respondo diretamente pelos comentários mas, desta vez, achei interessante trazer para o blog já que temos uma questão importante de desempenho envolvida.

Vamos lá!

O Desafio

O desafio é otimizar uma query muito ineficiente, que vai ao banco de dados por diversas vezes, uma para cada registro necessário à composição de uma view. Veja o código abaixo:

public class PedidoService
{
    private readonly AppDbContext _context;

    public PedidoService(AppDbContext context)
    {
        _context = context;
    }

    public List<PedidoComClienteDto> ObterPedidos()
    {
        var pedidos = _context.Pedidos.ToList();

        var resultado = new List<PedidoComClienteDto>();

        foreach (var pedido in pedidos)
        {
            var cliente = _context.Clientes.FirstOrDefault(c => c.Id == pedido.ClienteId);

            resultado.Add(new PedidoComClienteDto
            {
                PedidoId = pedido.Id,
                Data = pedido.DataCriacao,
                NomeCliente = cliente?.Nome
            });
        }

        return resultado;
    }
}

public class PedidoComClienteDto
{
    public int PedidoId { get; set; }
    public DateTime Data { get; set; }
    public string NomeCliente { get; set; }
}

Repare que, nesta abordagem, para cada pedido existente na base, será feita uma nova consulta para seu respectivo cliente. Ou seja, quanto mais a tabela de pedidos cresce, mais consultas são realizadas, mais rede é consumida, e mais demorada é a resposta. E pior, existe uma alocação tremenda de memória porque a transformação de IEnumuerable<PedidoComClienteDto> em List<PedidoComClienteDto> duplica a quantidade de objetos alocados, pois os que pertencem ao IEnumerable tem cópias criadas para a List por conta da natureza lazy de IEnumerable versus a eager da List.

Um verdadeiro horror!

A Solução

A solução mais elegante que encontrei, cujos números você poderá ver no benchmark que estará no final deste bloco, faz algo muito interessante. Em vez de ir ao banco uma vez para cada cliente demandado por um pedido, apenas uma conexão é necessária para trazer todo o conteúdo de pedidos e clientes para a memória e, então, criar as views.

Aqui segue o código:


public IList<CustomerIdentifiedOrderViewAsStruct> Solution()
{
    using var dbContext = new AppDbContext();

    var result = dbContext.Orders
                          .Include(o => o.Customer)
                          .AsNoTracking()
                          .AsValueEnumerable()
                          .Select(order => new CustomerIdentifiedOrderViewAsStruct
                          {
                              OrderId = order.Id,
                              CreationDate = order.CreationDate,
                              CustomerName = order.Customer!.Name
                          })
                          .ToList();
    return result;
}

[StructLayout(LayoutKind.Sequential, Pack = 4)]
public readonly record struct CustomerIdentifiedOrderViewAsStruct(int OrderId, DateTime CreationDate, string CustomerName);

Antes de mais nada, perceba como este código é muito mais simples e direto ao ponto. Existe apenas uma consulta, relacionando os pedidos com seus respectivos clientes, e todo o resto do trabalho é feito em memória.

Além de realizarmos menos idas ao banco, repare no método AsNoTracking(). Ele é um método do EF Core para trabalhar com consultas cujos dados devam servir apenas para leitura, ou seja, não serão modificados e persistidos. Isso melhora muito a velocidade e a alocação em memória porque dispensa o EF Core de criar os rastreadores para os objetos criados na query.

Se você leu meu post sobre o ZLinq deve ter percebi que ele está em uso nessa solução por conta do método AsValueEnumerable(). A ideia é reduzir dramaticamente a quantidade de alocações para economizar memória e reduzir, com isso, a pressão sobre o Garbage Collector.

Além disso, a própria view foi transformada em um record struct em vez de uma classe para reduzir as alocações. Repare no atributo StructLayout, ele serve para indicar ao compilador como os bytes da struct devem ser arranjados para melhor uso da stack. Escrevi este post a respeito, vale a leitura!

Apesar desta solução ser ótima do ponto de vista de desempenho, há algumas considerações que gostaria de fazer do ponto de vista de design.
Em primeiro lugar o ideal é evitar o uso de um único DbContext para toda a aplicação. Isso porque haverá uma pressão enorme para que consultas como a do desafio sejam feitas. Neste cenário em especial, o ideal seria que cada DbContext estivesse encapsulado em um módulo (Pedido ou Cliente) e que o módulo de Pedido pudesse pedir uma coleção de Clientes com base em uma coleção de ID. Isso manteria o código coeso do ponto de vista de cada módulo e, ao mesmo tempo, manteria os módulos isolados, evitando um acoplamento que levaria o código à famosa Grande Bola de Lama (Big Ball of Mud).

O ideal, do meu ponto de vista, seria o serviço de pedidos trabalhar com eventos de domínio que, a partir de uma projeção, geraria essa view, para que ela pudesse ser obtida com uma única consulta a partir de quem precisa desse dado.

Mas, como é um exemplo meramente ilustrativo, não há o menor problema em estar como está!

E, aqui, o benchmark dos dois codigos. Ambos utilizando a mesma base, com 100.000 pedidos e 100.000 clientes.

Diferença assombrosa. Não? Pois é!

Show me the Code

Como sempre o código desta demonstração está disponível no GitHub. Ela utiliza SQLite e, portanto, não exige o uso de Docker nem mesmo de uma instância de qualquer banco. É baixar, rodar, e modificar como quiser.

Conclusão

Apesar de ser um desafio de desempenho, é preciso sempre levar questões de design em consideração para que a aplicação seja modular e, com isso, mais fácil de evoluir. Ao mesmo tempo, conhecer mais profundamente ferramentas como o EF Core e o ZLinq te ajudam a considerar desempenho quando trabalhando com consultas.

Gostou? Me deixe saber pelos indicadores. Alguma dúvida ou comentário? Diga aqui na caixa de comentários ou me procure nas redes sociais, onde costumo responder mais rapidamente.

Muito obrigado por ler até aqui e até a próxima.

Crítica - MediatR: Pra Quê?

William Santos — Mon, 23 Jun 2025 17:05:59 +0000

Olá!

Este é um post da seção Crítica, e nele pretendo explorar o uso da biblioteca MediatR em aplicações reais e provocar uma reflexão a respeito.

Vamos lá!

O que é o MediatR?

Antes de adentrarmos a provocação proposta, vamos entender sobre o que estamos falando.

O MediatR se propõe a ser uma implementação do padrão Mediator (em inglês) que, basicamente, é um meio de propagar mensagens sem que seu produtor precise conhecer seus consumidores.

Além disso, a biblioteca possui uma implementação que sugere a mesma como um roteador de comandos e consultas, o que faz com que muitos imaginem, erroneamente, ser uma implementação de CQRS, o que explico neste post.

E é aqui que começamos a entender o problema.

O Problema

Quando o MediatR é utilizado para propagar comandos, a intenção é impedir que um Controller, por exemplo, tenha um "Constructor Dependency Explosion", ou seja, que tenha uma série de dependências injetadas via construtor e passe a depender, apenas, de uma instancia de IMediator.

Isso traz algumas questões:

O problema original é a necessidade de utilizar várias dependências para a execução de um único comando ou consulta, e não é o uso do MediatR que vai resolver, ele vai apenas mascarar pois seus handlers tendem a continuar com a explosão de dependências em seus construtores, ainda que em número menor ao do Controller.
Ao utlizar o MediatR adiciona-se uma camada de indireção por meio de sua interface IMediator, o que obriga o programador a buscar a implementação do handler correspondente àquela operação para entender o que se passa.
Normalmente o uso do MediatR esconde uma falha de design imensa que é a criação de uma quantidade enorme de handlers com uma quantidade enorme de código, disfarçando o que o Controller escancararia: código excessivo.
Toda vez que um Controller que utiliza IMediator é construído, também é uma instância do Mediator, uma vez que sua configuração padrão o cria como uma instância transiente.
Um componente fundamental de sua aplicação, seu roteador de operações, passa a ser uma dependência externa, o que te torna vulnerável a eventuais falhas, as famosas breaking changes ou até mesmo, como é possível ver aqui, uma mudança de licenciamento. Ou seja, não é mais um simples apoio, passa a ser um custo difícil de reverter.

Ou seja, em parte significativa dos casos, a maioria na minha experiência, o MediatR apenas mascara uma deficiência do design da aplicação, tornando-a mais complexa e mais difícil de ler.

Que Vantagem Maria Leva?

Diante das questões apresentados acima, proponho a seguinte pergunta: qual o ganho real que o uso do MediatR te traz?

É esconder a bagunça? Então ele só piora.
É separar responsabilidades? Então você não precisa dele.
É isolar dependências? Então você não precisa dele.

Entendo que faça sentido buscar responder a essa pergunta, indo além das questões aqui colocadas. Ou seja, considerando qualquer outro uso que você entenda fazer sentido para a biblioteca.

Aliás, te incentivo a trazer nos comentários do post, ou nas minhas redes, quais ganhos você percebe no uso da biblioteca que compense seus custos. Seria excelente ter pontos de vista diversos pra que eu mesmo considere, ou reconsidere.

MediatR é de Fácil Replicação

Por último, depois de responder a pergunta cima, ofereço uma alternativa super simples: construir um mediador você mesmo. No fim do dia, tudo de que você precisa é de uma interface que te permita percorrer uma lista de handlers e escolher o adequado para executar sua operação.

Nesta série de posts, meu colega e referência na comunidade .NET, Angelo Belchior, demonstra como é simples. Ele não pretende criar uma réplica utilizável em produção, apenas te guiar para uma implementação própria.

Conclusão

Evito ao máximo o uso do MediatR como um roteador de comandos e consultas, prefiro injetar meus handlers diretamente no Controller correspondente à operação que pretendo realizar.
Acho a biblioteca ruim? Nem de longe, tenho até um tutorial sobre ela aqui no Blog.
Mas entendo não haver ganhos significativos diante das questões apresentadas a menos que a aplicação se beneficie (como se beneficia a do exemplo do tutorial) e, por isso, ofereço uma solução alternativa no post sobre mal-entendidos em CQRS já referenciado (mas que você pode acessar por aqui também).

Gostou deste formato de post? Deixe-me saber pelos indicadores. Tem alguma dúvida ou comentário? Por favor, descreva abaixo.

Muito obrigado por ler até aqui e até o próximo post!

Desempenho - Aprimorando Span com ZLinq

William Santos — Wed, 21 May 2025 11:43:51 +0000

Olá!

Este é mais um post da seção Desempenho e, desta vez, vamos tratar de uma ferramenta muito útil que nos auxilia a lidar com Span<T>: O ZLinq.

Vamos lá!

Motivação

Como sabemos, não é possível escrever expressões Linq sobre spans e, por isso, é comum termos de iterar em coleções acessadas por esse tipo para realizamos operações.

O ZLinq ambiciona mudar esse comportamento!

Por meio de um método que tranforma seu Span<T> em um ValueEnumerable e permite que, em sua superfície, sejam executadas expressões como aquelas do Linq -- digo como aquelas do Linq e não as deste porque as expressões são todas implementadas pela própria biblioteca, que alega ter 99% das implementações do Linq (como os métodos Select, Where e Aggregate por exemplo).

Aqui temos um exemplo do benchmarking realizado para fins de teste desta biblioteca:

[MemoryDiagnoser]
public class ZLinqBenchmark
{
    [Benchmark]
    public int Linq()
    {
        DummyAccount[] dummies = new DummyAccount[1_000];
        for(int i = 0; i < dummies.Length; i++)
            dummies[i] = new (Guid.NewGuid(), i * 100);

        return
        dummies.Where(d => d.Balance > 1_000)
               .Select(d => d.AccountId)
               .Count();
    }

    [Benchmark]
    public int ZLinq()
    {
        Span<DummyAccount> dummies = stackalloc DummyAccount[1_000];
        for (int i = 0; i < dummies.Length; i++)
            dummies[i] = new(Guid.NewGuid(), i * 100m);

        return
        dummies.AsValueEnumerable()
               .Where(d => d.Balance > 1_000)
               .Select(d => d.AccountId)
               .Count();
    }
}

Como podemos observar, não há grandes diferenças entre os usos do Linq e Zlinq, na verdade há apenas duas: o método Linq utiliza um array, enquanto o ZLinq utiliza um Span<T> e; o método ZLinq lança mão do ValueEnumerable.

Essas simples diferenças produziram o seguinte resultado no benchmarking:

Repare nas alocações: é uma economia de 32k por execução. Agora imagine isso no caminho crítico de uma aplicação, como oferece um desempenho superior por conta da necessidade reduzida de acionamentos do Garbage Collector. Impressionante!

Algo interessante aqui: em cenários onde os dois testes utilizem IEnumerable com tipos complexos, e o ZLinq não utilize um Span<T>, alocações passam a ocorrer, como aquelas que ocorrem com o Linq.

Veja:

Além da alocação próxima, o tempo de execução foi um pouco maior. Ter esse conhecimento é interessante para evitar o uso indiscriminado da biblioteca. O ideal é utilizá-la quando há um cenário propício, no caso quando se usa Span<T>.

Conclusão

ZLinq é uma ferramenta que entrega um desempenho ótimo ao lidarmos com Span<T> tendo a necessidade de utilizar expressões Linq.
A biblioteca ainda está em começo de vida, conta com pouco mais de 20k downloads, mas é mantida pelo mesmo criador do MessagePack-CSharp sobre o qual já falamos aqui.
Vale a pena esperar por mais funcionalidades e melhorias com o tempo.

O código do benckmark está, como sempre, disponível no Github. Divirta-se e me diga o que achou.

Gostou do post? Me deixe saber pelos indicadores. Tem dúvidas ou sugestões? Deixe um comentário ou me procure em minhas redes.

Muito obrigado por ler até aqui, e até o próximo post.

Dica Rápida: Ganhando desempenho com o modificador Sealed

William Santos — Mon, 14 Apr 2025 12:07:21 +0000

Olá!

Esta é mais uma Dica Rápida e aqui vou demonstrar como uma simples palavra-chave da linguagem pode fazer o desempenho de sua aplicação aumentar.

Parece inacreditável? Pois acredite, não é!

Conhecendo a palavra-chave sealed

sealed é uma palavra-chave que indica que uma dada classe não pode ser herdada, ou seja, que ela está fechada para extensão.

O que essa palavra-chave esconde é uma informação muito útil ao compilador que, grosso modo é, ao visitar um método de uma classe sealed é líquido e certo que seu tipo não conterá qualquer derivação e, por isso, o compilador just in time (JIT) sabe que não precisa identificar se o tipo é herdado ou não. Um outro ponto é que, por conta desta identificação inequívoca, um método/membro invocado de uma classe sealed pode ser colocado em linha com o invocador, deixando a chamada mais rápida -- como quando se usa o atributo [MethodImpl(MethodImplOptions.AggressiveInlining)].

Veja só um exemplo de benchmarking bastante simples, baseado no código abaixo:

public class Sealed
{
    public class BaseType { public virtual int GetInt() => 1; }
    public class NonSealedType : BaseType { public override int GetInt() => 10; }
    public sealed class SealedType : BaseType { public override int GetInt() => 10; }

    private readonly NonSealedType nonSealed = new();
    private readonly SealedType @sealed = new();

    [Benchmark(Baseline = true)]
    public int GetIntNonSealed() =>
        nonSealed.GetInt() + 42;

    [Benchmark]
    public int GetIntSealed() =>
        @sealed.GetInt() + 42;
}

E o resultado foi o seguinte:

Repare na diferença: quase 15x a favor da classe sealed!

Por conta desta vantagem o time do .NET vem modificando e criando classes internas e privadas do runtime do .NET para sealed, de modo a melhorar seu desempenho -- aqui um post a respeito do assunto (em inglês).

Como regra do polegar, recomendaria o seguinte:

Se a classe é privada/interna e não é herdada, então sealed.
Se a classe é pública e não é desejável que ela seja herdada, então sealed.
De outro modo não faz sentido aplicar a palavra-chave.

Gostou? Me deixe saber pelos indicadores. Caso deseje, deixe um comentário ou me procure nas redes sociais.

Até a próxima!

Design: Event Sourcing (5 anos depois)

William Santos — Mon, 31 Mar 2025 12:20:38 +0000

Olá!

Este é mais um post da seção Design e nele trago uma atualização da série sobre Event Sourcing, de 2020. Como o blog está comemorando 5 anos, entendi fazer sentido ilustrar o padrão com uma aplicação funcional.

Este post foi inspirado pelo livro de Martin Dilger chamado Understanding EventSourcing (em inglês). Sua abordagem é bastante interessante e, além disso, inclui uma explicação completa sobre modelagem de domínio orientada a eventos, a Event Modeling, concebida por Adam Dymitruk.

No repositório deste post estão diagramas de Event Modeling, que vou explorar no próximo post. Portanto não se preocupe caso sua leitura não seja óbvia logo de início.

Antes de mais nada, muito obrigado!

Antes de começarmos a explorar a aplicação, quero agradecer a você que esteve acompanhando este blog desde o início, 5 anos atrás. O apoio da comunidade é um excelente combustível para continuar a escrever (mesmo que com um hiato no meio do caminho) e cada curtida, comentário e compartilhamento ajuda muito. Então, muito obrigado!

Sigamos.

Event Sourcing

Os módulos da aplicação de demonstração empregam este pattern para registrar o histórico de suas mudanças de estado enquanto, ao mesmo tempo, nos permite criar projeções (visões) nos mais diferentes moldes para uso analítico pelo negócio.

Vamos ver o que o livro nos diz a esse respeito (em tradução livre): "É sobre armazenar informações e construir diferentes visões a partir dos dados na EventStore. (...) Eventos são simples fatos e de forma alguma técnicos. Sempre que algo acontece no sistema nós armazenamos como um Evento. Então, em termos simples, Eventos são registros do passado, portanto os escrevemos no passado. Em vez de 'cliente enviando um pedido' dizemos 'Um pedido foi enviado', ou encurtando, 'PedidoEnviado'. Um pedido foi enviado e não há como mudar esse fato. Mesmo excluindo o pedido de sua base de dados não mudará o fato de que um pedido foi enviado antes".

Snapshots

Como dito no post original sobre o tema, snapshots são uma forma útil de reduzir a carga sobre nosso Event Store, criando um ponto de restauração e demandando que apenas os eventos que lhes sejam posteriores sejam carregados, fazendo com que a obtenção de nosso modelo de escrita, nossa entidade, tenha um desempenho melhor.
O livro sugere o mesmo em outras palavras (como sempre, em tradução livre): "Snapshots podem ser usados quando você deseja limitar o número de eventos que você precisa preocessar em uma stream. Visto por esse ângulo, snapshots servem a um propósito semelhante ao cache: nós adicionamos ao cache o estado projetado do sistema em vez de calculá-lo em tempo de execução."

Projeções

Como dito acima, Event Sourcing nos permite criar projeções à medida em que os eventos ocorrem. Podemos criá-las a partir de qualquer requisito de negócio que envolva os dados dos eventos, e no mesmo momento em que estes são persistidos.
Ou seja, podemos criar entradas de relatórios em tempo real, escolhendo uma estratégia que pode variar de acordo com os requisitos do negócio. Ao receber os eventos do sistema, o responsável pela criação das projeções pode, por exemplo, iterar em uma lista de Projetores para em cada um, gerar um projeção analítica diferente. Quando houver a necessidade de mais projeções, um novo projetor pode ser adicionado.

Em nossa aplicação há o módulo Accounts, que atende à conta de um dado cliente. Esta conta pode sofrer créditos e débitos ao longo de seu ciclo de vida e, graças ao emprego de Event Sourcing, podemos extrair dados que respondam a perguntas como "quantos depósitos foram feitos pelos clientes no mês de março versus o mês de fevereiro?", ou "qual o valor total em depósitos dos clientes ao longo dos últimos doze meses?".
Responder a essas perguntas é importante para o negócio, dado que decisões estratégicas podem ser tomadas a partir delas.

CQRS

Como dito no post original sobre o assunto, CQRS nos fornece uma forma de persistir projeções que atendam às necessidades da nossa aplicação. No caso da conta do cliente mencionado acima, podemos criar um modelo tão simples quanto o identificador do cliente e seu saldo (como fazemos na aplicação de demonstração) para que seja exibido, por exemplo, na tela inicial de um app ou numa página de um sistema web. Vale lembrar que é possível criar visões diferentes a partir de um mesmo evento, ou seja, seria possível também criar uma entrada de extrato com o que foi depositado/retirado pelo cliente, facilitando assim a exibição dos dados.

Consistência

Algo muito importante ao se falar sobre CQRS é que muito se pensa que CQRS demanda, necessariamente, consistência eventual, e isso é um erro. Vamos recorrer ao livro mais uma vez para ilustrar esse caso (mais uma vez em tradução livre): "Para muitos projetos a solução mais simples para atualizar todas as partes do sistema de uma vez é usar uma mesma base de dados para os modelos de escrita e leitura, o que não é proibido e nem uma má prática. Se você estiver utilizando um banco PostgreSQL para armazenar seus eventos assim como suas projeções é normalmente suficiente atualizá-los dentro de uma mesma transação. Essa abordagem garante consistência e simplifica muito o sistema, tornando fácil entender a respeito. Não subestime as vantagens da simplicidade. Eu me desviaria dela apenas se você tiver razões muito boas."

Em nossa aplicação de demonstração utilizei as duas formas de consistência, eventual para o módulo Account, e imediata, na mesma transação de armazenamento dos eventos, para os demais. Ao ler o código vai ficar clara a diferença entre ambas as abordagens, ainda que tenha simplificado muito a abordagem da consistência eventual para rodar no mesmo processo que a Web API.

Bom, falamos algumas vezes sobre a aplicação de demonstração. Certo? Hora de conhecê-la!

Conhecendo a aplicação

Esta aplicação é um monolito modular composto pelos seguintes módulos:

Account (Como já mencionado, atende à conta do cliente e suas movimentações)
Orders (Ordens de compra e venda de ações)
Exchange (Um simulador do comportamento da bolsa de valores, que executa as ordens)
Positions (A visualização das ações que o usuário possui)

Esses módulos são utilizados por uma Web API que expõe suas funcionalidades e compartilham a EventStore para registrar os eventos, assim como a Snapshot Store para os snapshots.

Introdução - Os fluxos

Existem dois fluxos na aplicação, o de compra e de venda de ações.

O fluxo de compra começa com um crédito em conta (Deposit na WebApi), passa pela colocação de uma ordem (PlaceOrder) que tem sua execução realizada pelo simulador de execução da bolsa de valores (Execute) e termina com a possibilidade da consulta às ações compradas, que formam a posição do cliente (Positions).

Já o fluxo de venda segue o caminho inverso. A partir das ações compradas coloca-se uma ordem de venda (PlaceOrder), que também é executada pelo simulador da bolsa de valores (Execute) e que gera um depósito na conta do cliente, o que lhe permite um saque (Withdrawal).

A Web API vem com um Swagger que te permite executar todos os comandos e consultar seus efeitos colaterais.

Parte 1 - Eventos

Para aplicarmos o Event Sourcing criamos uma classe abstrata com o necessário para que todo e qualquer agregado consiga fazê-lo. Esta classe chama-se EventBasedEntity. Veja o código abaixo:

namespace WSantosDev.EventSourcing.Commons.Modeling
{
    public abstract class EventBasedEntity
    {
        public int Version { get; protected set; }
        public List<IEvent> UncommittedEvents { get; } = new ();

        protected void RaiseEvent<TEvent>(TEvent @event) where TEvent : IEvent
        {
            Version++;
            UncommittedEvents.Add(@event);
            ProcessEvent(@event);
        }

        protected void FeedEvents(IEnumerable<IEvent> stream)
        {
            foreach (var @event in stream)
            {
                Version = @event.Id;
                ProcessEvent(@event);
            }

            Version++;
        }

        protected abstract void ProcessEvent(IEvent @event);
    }
}

Para facilitar a compreensão do código acima, vamos vê-lo em ação em nosso agregado Account e, em seguida, explicamos o conjunto.

...

public Result<IError> Credit(Money amount)
{
    if (amount <= Money.Zero)
        return Result<IError>.Error(Errors.InvalidAmount);

    RaiseEvent(new AmountCredited(Version, amount));

    return true;
}
...

protected override void ProcessEvent(IEvent @event)
{
    switch (@event) 
    {
        case AccountOpened accountOpened:
            Apply(accountOpened); break;
        case AmountCredited amountCredited:
            Apply(amountCredited); break;
        case AmountDebited amountDebited:
            Apply(amountDebited); break;
    }
}
...

private void Apply(AmountCredited @event) =>
    _entries.Add(Entry.Credit(@event.Amount));

Repare que o código de Account complementa o de EventBasedEntity. Agora vamos às explicações.

Quando um método do nosso agregado é acionado, seus argumentos são checadas (no caso se o valor depositado é maior que zero) e, em caso positivo, um evento é lançado. Neste caso lançamos o evento AmountCredited, via RaiseEvent, que vai atualizar o estado do módulo.

Você pode estar se perguntando: mas não é mais simples apenas atribuir o valor do depósito a uma propriedade Balance e seguir a vida? E a resposta é: não!

Veja, quando lançamos um evento, alimentamos a lista UncommitedEvents que representa o conjunto de eventos que ainda não foi persistido em nossa Event Store. E, como veremos à frente, essa lista é o que dá sentido ao Event Sourcing, da mesma forma que a versão do nosso agregado.

Parte 2 - EventStore

Algo interessante a dizer sobre a Event Store é que ela é agnóstica a mecanismo de persistência. Você poderia utilizar um arquivo caso quisesse -- isso não é uma recomendação!

Em nossa demo utilizamos SQLite dado que bancos relacionais são a realidade da maioria de nós, mas poderia ser qualquer outro mecanismo de persistência que nos permita escrever uma versão serializada de nossos eventos, como vemos no código abaixo:

...
public sealed class EventDbContext(DbContextOptions<EventDbContext> options) : DbContext(options)
{
    private DbSet<Event> Events { get; set; }

    public void AppendToStream(string streamId, IEnumerable<IEvent> events)
    {
        var eventsToAppend = events.Select(e => EventSerializer.Serialize(e.Id, streamId, e));
        Events.AddRange(eventsToAppend);
    }
}

internal record Event(int Id, string StreamId, string Created, string EventType, string Data);

Nota: utlizamos EF Core por simplicidade. Seu uso não é uma necessidade, assim como não é necessário qualquer outro ORM. O importante é ter acesso ao mecanismo de persistência e fazer operações de escrita de cada evento.

Repare que no código acima, o método AppendToStream espera um streamId e um tipo enumerado de IEvent, que é a lista UncommitedEvents que temos em nosso agregado.

Repare também que os eventos são serializados para preencher a entidade Event que será o registro de fato armazenado na base de dados.

Vamos ver como funciona essa serialização:

internal sealed class EventSerializer
{
    ...

    public static Event Serialize<TEvent>(string streamId, TEvent @event) where TEvent: IEvent
    {
        return new(eventId,
                   streamId,
                   DateTime.UtcNow.ToString("yyyy-MM-dd HH:mm:ss"),
                   @event.GetType().FullName!,
                   JsonSerializer.Serialize(@event));
    }
}

Então você poderia me perguntar: mas por que serializar? Por que não persistir o agregado e seguir a vida? Repare que recebemos TEvent como parâmetro, isso para podermos permitir que qualquer tipo de evento seja persistido na base sem que tenhamos de nos preocupar com sua forma (nos preocupamos apenas com seu tipo para permitir a desserialização no futuro). Deste modo é muito mais simples persistir e é exatamente essa simplicidade que nos dá a flexibidade para escolher qualquer meio para persistir nossos eventos.

Com este código conseguimos persistir os eventos que constituem o agregado com sucesso, precisando apenas recuperá-los em ordem (daí a importância do Version em EventBasedEntity) para restaurá-lo e poder operar com ele.

Parte 3 - Snapshot

Como dito acima, às vezes temos um ciclo de vida muito longo para um agregado. Uma conta, por exemplo, pode existir e ser movimentada por anos, o que, em grande volume de usuários, poderia comprometer o desempenho do sistema.

Assim sendo, podemos criar snapshots a partir do código abaixo, que nos permite definir um tipo que será persistido e poderá ser recuperado no futuro para facilitar a restauração do agregado.

Veja como funciona o snapshot pelo código de Account

public sealed partial class Account : EventBasedEntity, ISnapshotable<AccountSnapshot>
{
    public bool ShouldTakeSnapshot() => _entries.Count % 3 == 0;

    public AccountSnapshot TakeSnapshot() =>
        new (AccountId, Version, [.. _entries]);
}

A interface ISnapshotable<T> nos fornece os dois métodos acima para decidir se devemos ou não criar um snapshot e para gerar o tipo de snapshot que será persistido.

Aqui usamos o tipo AccountSnapshot que é uma representação do estado atual do agregado, neste caso seu id, sua versão e o conjunto de entradas que possui neste momento. Da mesma forma que um evento, este snapshot será serializado e persistido, com a diferença de que novos snapshots vão sobrescrever o original em vez de ser adicionados para viver junto com ele.

Parte 4 - Projeções

Aqui temos a criação de nosso modelo de leitura (ou view) que será consultado quando necessário pela nossa aplicação.

Nota: no caso específico de Account optamos por simular um modelo de consistência eventual, e digo simular porque, em vez de utilizarmos um mecanismo de mensageria (como o RabbitMQ) ou event stream (como o Kafka), para receber os eventos de domínio e convertê-los em projeções, utilizamos um bus em memória por simplicidade.

No caso de Account, sempre que um evento do Event Sourcing é lançado, o comando que operou sobre o agregado irá lançar um evento de domínio correspondente, que será interceptado por um manipulador de eventos de domínio que o converterá em uma projeção.

Nota: No caso dos demais módulos optamos por um modelo de consistência imediata. Em vez de lançarmos um evento de domínio correlato ao comando executado, persistimos a projeção na mesma transação em que persistimos os eventos do Event Sourcing (o que só é possível porque ambas as persistências estão na mesma base). Vale a pena examinar as diferenças entre ambas as abordagens.

Vamos examinar um desses manipuladores de eventos de domínio para entender como a projeção é criada.

public class AccountOpenedHandler(AccountViewDbContext viewDbContext) : IMessageHandler<AccountOpened>
{
    public async Task HandleAsync(AccountOpened message)
    {
        var view = AccountView.Create(message.AccountId, message.InitialDeposit);
        viewDbContext.Add(view);

        await viewDbContext.SaveChangesAsync();
    }
}

Veja que é um manipulador bem simples, que reage a abertura de uma conta. Ele apenas cria uma projeção da conta, com seu id e o valor de seu depósito inicial, e o persiste em uma base de views (que, em nosso caso, é a mesma base onde persistimos os eventos, mais uma vez por simplicidade).

Pronto! A partir de agora podemos consultar essa projeção para sabermos qual é o saldo de uma conta no momento da consulta.

Repare em algo interessante: essa view é uma versão customizada de nosso agregado e sequer é fiel a ele. Não existem entradas, apenas o id da conta e seu saldo. Isso porque é apenas esse dado de que precisamos na aplicação. Se precisássemos de um histórico de transações, um extrato, poderíamos criar uma segunda view que contivesse o número da conta, a data da movimentação, seu tipo (abertura de conta, crédito ou débito) e o valor.
Esse é o poder do CQRS: é possível criar qualquer visualização desejada a partir do estado da aplicação, inclusive para, como dito acima, a geração de relatórios que a aplicação não consuma e que sirva apenas a fins analíticos.

Excelente! Não?

Parte 5 - Juntando as peças

Agora que entendemos as peças fundamentais do Event Sourcing/CQRS, podemos examinar nossa Web API que é quem fornecerá nossas funcionalidades ao mundo.

Aqui encontraremos comandos e consultas que nos permitirão, a partir da nossa necessidade, obter dados das projeções ou restaurar o estado de nosso agregado para realizar operações.

Vamos ver um exemplo do controller de crédito em conta.


public class CreditController(Credit command) : ControllerBase
{
    [HttpPost("Credit")]
    [ProducesResponseType(StatusCodes.Status200OK)]
    [ProducesResponseType(StatusCodes.Status404NotFound)]
    [ProducesResponseType(StatusCodes.Status500InternalServerError)]
    public async Task<IActionResult> Credit(CreditRequest request)
    {
        var credited = await command.ExecuteAsync(new CreditParams(Constants.DefaultAccountId, request.Amount));
        if (credited)
            return Ok();

        if (credited.ErrorValue is InvalidAmountError)
            return BadRequest($"Invalid amount. The amount should be greater than zero.");

        return StatusCode(StatusCodes.Status500InternalServerError, "Unspecified error.");
    }

Aqui temos o seguinte: recebemos uma instância de um comando de crédito que encapsula toda a lógica necessária a essa operação. Ele restaura o agregado, invoca seu método de crédito, persiste e lança o evento de domínio correspondente. No controller temos apenas a execução do comando com seus respectivos parâmetros (o id da conta e o valor do depósito).

Se o comando for bem sucedido, retornamos um Ok (200), do contrário, se a falha ocorreu por conta da invariante do agregado (depósito com valor maior que zero), retornamos um Bad Request (400) e, caso a falha seja de outra natureza, retornamos um InternalServerError (500).

Simples. Não?

Vertical Slices

Repare que nosso controller se chama CreditController, ou seja, ele se responsabiliza apenas pelo depósito de valores na conta de um cliente. Essa abordagem, que é orientada a tarefas e não a recursos, se chama vertical slices (fatias verticais em tradução livre), e é uma forma de segregar as ações possíveis no software de acordo com seu propósito.
Ou seja, para verificarmos o saldo em conta de um cliente, teremos um BalanceController, para realizar um débito na conta, um DebitController e por aí vai. Isso em vez de ter um único controller que reúna todas as operações possíveis em Account, o que pode se tornar difícil de manter e evidencia a simplicidade do próprio design da aplicação (se um controller está muito grande, é possível que o design não esteja adequado à solução).

Aqui temos uma breve apresentação deste padrão segundo o livro (sempre em tradução livre): "Até onde sei o termo 'Vertical Slice Architecture' foi cunhado por Jimmy Bogard em uma série de artigos por volta de 2019. Seu principal mote é 'minimizar o acoplamento entre as fatias e maximizar o acoplamento dentro de uma fatia'".

Pode soar um pouco estranho ler o trecho "maximizar o acoplamento dentro da fatia", mas foi exatamente o que fizemos em nosso caso. Temos um controller apenas para a fatia de crédito, assim como um manipulador de comando e um evento de domínio. Todos esses elementos bastante acoplados entre si pois são todos dependências da funcionlidade de crédito.

Nota: assim como tratado no post CQRS - Desfazendo mal-entendidos, não há a menor necessidade de utilizarmos o famoso MediatR. Implementamos a injeção do manipulador de comando diretamente no controller pois nossa intenção é realizar uma única operação, o que acaba por tirar a razão de existir do MediatR que é notificar N manipuladores de forma desacoplada. Vale a pena evidenciar a ausência de ligação entre uma coisa e outra.

Conclusão

Como pudemos ver, Event Sourcing traz uma vantagem e um poder enorme para uma aplicação, nos permitindo conhecer por completo o histórico de mudanças de seu estado e, ao mesmo tempo, provendo uma forma de gerar visões distintas para propósitos específicos. É evidente que Event Sourcing não é uma necessidade para toda e qualquer aplicação mas, quando faz sentido, é um instrumento poderossímo e aliado do negócio -- que é a razão pela qual a aplicação existe.

Espero que tenha gostado desta releitura 5 anos depois e que se divirta com o código da aplicação de demonstração para conhecê-la em detalhes.

Se gostou, me deixe saber pelos indicadores do post e, caso queira, deixe um comentário, principalmente se tiver alguma dúvida.

Muito obrigado pela leitura e até o próximo post!

Playground: Jan Ken Po

William Santos — Sun, 08 Sep 2024 16:03:32 +0000

Olá!

Este é mais um post da seção Playground e, neste, não trago nada de mais além de um pouco de saudosismo.

Pois é! O famoso jogo de Pedra, Papel e Tesoura foi o primeiro programa que escrevi além da sala de aula e, enquanto jogava Alex Kidd in the Miracle World DX, acabei me lembrando disso e escrevendo uma versão bem simples em C# apenas por diversão - diversão esta que compartilho agora por aqui.

Como de costume o código está no GitHub.

Espero que goste. Apesar de um post mais simples, espero seu feedback. Se tiver gostado, me deixe saber pelos indicadores. Fique à vontade, também, para me procurar em minhas redes sociais.

Até mais!

Além do Código: Linguagem Ubíqua e Idioma do Código

William Santos — Mon, 19 Aug 2024 11:02:47 +0000

Olá! Este é um post da seção Além do Código, onde pretendo discutir algumas questões que influenciam o desenvolvimento de software mas não necessariamente tratam de implementações.

Neste post falarei um pouco sobre a relação entre Linguagem Ubíqua e o idioma utilizado no código. Esta é uma questão bastante frequente e, muito embora pareça simples, não é exatamente assim.

Vamos lá!

O que é a Linguagem Ubíqua

A Linguagem Ubíqua é um dos aspectos centrais em Domain-Driven Design (DDD) e diz respeito à forma como é feita a comunicação entre pessoas de negócio (especialistas de domínio) e engenharia dentro do que o DDD vai chamar de Contextos Delimitados, conceito que ficará para futuros posts.

Aqui temos uma definição muito boa de Martin Fowler a respeito, em tradução livre:

É a prática de construir uma linguagem comum e rigorosa entre desenvolvedores e usuários.
Deve se basear no modelo de domínio e, por isso, precisa ser rigorosa pois software não lida bem com ambiguidade.

Repare na palavra "rigorosa" acima. Ela indica que a linguagem deve ser a mais precisa possível a ponto de não admitir mais de um termo para se referir a um mesmo elemento do Modelo de Domínio (este também assunto para futuros posts), pois, desta forma, o risco de ruído na comunicação é drasticamente reduzido.

A questão do idioma

Quero discutir essa questão à luz do DDD, ou seja, como um praticante lidaria com ela. Ao mesmo tempo, levarei em consideração o fato de estarmos no Brasil e como isso influencia a decisão.

Código em Inglês

Muita gente acredita que codificar em inglês é o padrão e assim deve ser porque as linguagens de programação utilizam a lingua inglesa para oferecer suas instruções.

Quero desafiar esta noção com as seguintes perguntas:
1- Sendo a Linguagem Ubíqua baseada em elementos do negócio, faz sentido traduzi-los para o inglês no código se não for o idioma falado pelos especialistas de domínio? Seu time é capaz de garantir que não confundirá termos nos dois idiomas ao se comunicar com os especialistas de domínio de modo a levar esta confusão ao código?

2- Seu time tem fluencia não apenas em inglês como, também, nos termos de negócio quando nesse idioma? O código poderia ser lido por um anglófono (falante de inglês) de modo a ser compreendido sem a necessidade de recorrer a membros do time para "traduzir a tradução"?

Aqui é preciso lembrar que apenas 1% da população brasileira tem fluência em inglês e que, com certeza, nem todos nesse 1% atuam desenvolvendo software. Ou seja, as chances de haver erros importantes no código que possam criar confusão são grandes o bastante para gerar preocupação.

Exemplos simples

No mercado de capitais é muito comum falarmos em "ações". Ações são uma fração da propriedade de uma empresa e, em inglês, diz-se "stocks". Entretanto, em códigos que já tive a oportunidade de atuar, vi este termo traduzido literalmente como "actions".
Ao mesmo tempo, em contabilidade, há o termo "lançamento contábil", que é o ato de registrar uma movimentação financeira, que, em inglês, é chamado de "journal entry", e já o vi sendo traduzido como "launch", que é lançamento no sentido de projeção, como no lançamento de foguetes.

Partindo desses exemplos, deixo a pergunta: como um falante de inglês interpretaria esses termos? Faria sentido pra ele? E mais, se não é objetivo promover a interação de um anglófono, qual o sentido em traduzir os termos em primeiro lugar?

Código Híbrido

Esta é uma modalidade de código onde elementos técnicos são tratados em inglês, mas elementos do domínio são tratados, no nosso caso, em portugês.

Um exemplo simples seria uma classe chamada BoletoRepository, responsável pela persistência e recuperação de boletos junto a um banco de dados, cujo método de persistência seja Save e o de recuperação se chame GetById.

Aqui já temos um sinal claro de como essa abordagem pode ser problemática. Uma pergunta que eu faria é: o ID de um boleto é algo conhecido pelo negócio? Em caso positivo, é chamado de ID? Ou "identificador"? Se for chamado de identificador, há uma tradução que se torna difícil saber se este é um aspecto técnico (um ID na base de dados por exemplo) ou um aspecto de negócio. Ou seja, perde-se a rigidez pretendida pela Linguagem Ubíqua e pode-se gerar confusão, inclusive, caso um novo membro chegue à equipe, já que ele provavelmente entenderia, ao ler o código, tratar-se de uma questão técnica e não de negócio até que isso fosse esclarecido.
E aqui estamos falando apenas de um ID. Agora considere esse mesmo tipo de confusão distribuída pelo código por meio de diversos termos. Faz sentido assumir esse risco?

Código em Português

Este, talvez, seja o mais controverso entre os modelos possíveis. Isso porque existe, da mesma forma que uma predileção pelo inglês, uma forte rejeição ao português.

Vamos pegar o exemplo acima, de código híbrido, e fazer um teste:
Para o caso do repositório de boletos teríamos uma classe chamada RepositorioDeBoletos, com os métodos Salvar e ObterViaIdentificador. E então fica a pergunta: qual o real problema com este código? Ele é claro o bastante para indicar a ação sendo realizada bem como seu propósito e, mais importante, sendo português o idioma do negócio, o custo de tradução entre idiomas é zero. Ao mesmo tempo, por estar no idioma do negócio, um novo membro do time entenderia que o Identificador é um conceito de negócio e não um componente técnico. Parece bom. Não?

Isso significa que estou recomendando o uso de português? Não. Lembre-se de que, acima, afirmei que parece uma questão simples mas não é tanto, e agora vou explicar o porquê.

Determinismo Organizacional

Esse termo serve para dizer o seguinte: essa é uma questão cultural na organização. E aqui deixo três perguntas para provocar uma reflexão:
1- Sua organização tem/terá especialistas de domínio anglófonos, ou falantes de outros idiomas, demandando que toda a comunicação seja feita em inglês como língua franca?
2- Os membros do time estão aptos a codificar em inglês sem perder significados, evitando cair no problema da "tradução da tradução"?
3- Assumindo que sua organização contrate desenvolvedores de outros países, mas que mantenha o idioma do negócio em português, o que é mais barato? Qualificar os envolvidos para se comunicar em inglês? Ou trazer os anglófonos para o português?

Conclusão

Perceba que não há uma resposta simples e definitiva para esta pergunta. Cada organização precisa tratar do assunto com cautela, lembrando: caso optem por utilizar DDD como ferramenta para descrever o domínio, pois o custo de mudança é alto e as consequências podem ser negativas a depender da abordagem escolhida – é uma decisão mais importante do que parece!

Gostou deste post? Me deixe saber pelos indicadores. Fique à vontade para comentar ou me procurar em minhas redes sociais para prosseguir com o assunto.

Muito obrigado pela leitura, e até o próximo post.

Design: Imutabilidade

William Santos — Mon, 20 May 2024 13:00:37 +0000

Olá!

Este é mais um post da seção Design e, nele, falaremos sobre um conceito fundamental da programação funcional cada vez mais presente no universo orientado a objetos: imutabilidade.

A ideia é trazer as motivações, benefícios, e mostrar como é possível implementá-la usando C#.

Vamos lá!

O que é imutabilidade

Imutabilidade é a característica de uma dada instância de uma estrutura de dados de ter seu estado preservado, e imune a mudanças, uma vez criado. Isso significa que, quando um novo valor se fizer necessário a uma de suas propriedade, uma nova cópia desta instância.

Essa abordagem traz algumas vantagens, e algumas preocupações, algumas não muito óbvias, e vamos explorá-las a seguir.

Multi-threading e Paralelismo

A primeira grande vantagem trazida pela imutabilidade a preservação do estado de um objeto quando acessado por múltiplas threads (thread safety) ou em paralelo (concorrência). Em cenários onde um objeto é mutável é necessário criar mecanismo de sincronização (a forma mais comum é via lock) o que acaba trazendo complexidade à aplicação dado que o programador precisa se preocupar em checar se todo lugar que acessa esse objeto com a finalidade de mudar seu estado está sendo sincronizado adequadamente.

Uma vez que um dado objeto é imutável, todas as threads poderão acessá-lo para fins de leitura e, caso seja necessário promover uma mudança de estado, um novo objeto é criado e passa a ser compartilhável, sem a necessidade de se preocupar com locks.

Legibilidade, Debugging e Testes

Outra vantagem muito interessante, embora não tão óbvia, é o aumento da legibilidade do código, e da facilitação de testes e debugging.
Isso porque, como o objeto não sofre mudanças, basta procurar os pontos onde novos objetos são criados para verificar se há erro em sua inicialização, o que aumenta a eficiência já que é algo mais fácil de encontrar do que pontos de mudança, principalmente se essas mudanças não indicam o tipo do objeto que está sendo modificado (quando var é utilizado, por exemplo).

Desempenho

Dado que mudanças não são possíveis em um objeto, e a criação de uma nova instância é exigida, há um potencial uso aumentado de memória, sobretudo no caminho crítico da aplicação se houver um uso intensivo de recursos.
Nestes casos um design que considere esse uso intensivo e a necessidade de evitar mudanças é fundamental.
Linguagens funcionais são otimizadas para este cenário, com recursos como compartilhamento do endereço de memória das propriedades das instâncias, assim uma instância nova não precisa copiar dados, apenas referências, algo muito mais eficiente.

Imutabilidade e `C#`

Em suas últimas versões o time do .NET tem investido muito em recursos para tornar o C# compatível com imutabilidade, e vamos conferir os principais.

Readonly Structs

Este foi um dos primeiros recursos da linguagem para tratar imutabilidade. Quando declaradas com a palavra chave readonly a instância passa a ter mudanças impedidas. Desta forma, qualquer tentativa de mudança, inclusive por métodos da própria instância, não funcionará.

Vamos ver um exemplo em código:

public readonly struct Struct
{
    int _value;

    public Struct(int value) =>
        _value = value;

    public void Add(int value) =>
        _value += value;
}

public static void Main()
{
    var @struct = new Struct(3);
    @struct.Add(7);
    Console.Write($"Value: {@struct}"); //3
}

Nota: a forma pela qual o compilador garante a imutabilidade de readonly structs são as chamadas cópias defensivas (defensive copies). Em termos simples, toda vez que a instância precisa ser acessada, uma cópia dela em seu estado original é criada. Desta forma a instância original tem seu estado protegido, ainda que ao custo de maior consumo da stack. Há formas de resolver este problema, basicamente passando a instância por referência usando a palavra-chave in na assinatura do método que irá recebê-la, ou por meio do uso de ref readonly ao utilizar uma instância que esteja em um escopo maior.

Records

Outro tipo que traz imutabilidade por design é o record. Uma vez inicializado seus valores não podem mais ser alterados, o que torna possível ter classes imutáveis (uma vez que records são reference types).

Um detalhe que precisa ser levado em consideração, no entanto, é que records podem se tornar mutáveis caso suas propriedades sejam declaradas com setters. Ou seja, para tirar vantagem da imutabilidade as propriedades devem ser declaradas com initializers ou de forma posicional.

Vejamos exemplos:

public record Person
{
    public string Name { get; init; }
    public byte Age { get; init; }
}

É o equivalente a:

public record Person (string Name, byte Age);

Desta forma há a garantia de que nenhuma mudança possa ser realizada.

Campos Read-only

Este é um recurso bastante conhecido que, basicamente, informa que um dado campo de um objeto pode ser apenas lido e que, obrigatoriamente, será inicializado (ou por atribuição no momento da declaração, ou via construtor).

Vejamos como funciona:

public class Person
{
    public readonly String _name = "Person Name";
}

Que equivale a:

public class Person
{
    public readonly String _name;

    public Person(string name) =>
        _name = name;
}

Desta forma, uma vez inicializado, name não pode ter seu valor modificado.

Criando Novas Instâncias

Para facilitar a criação de novas instâncias, atribuindo apenas os valores novos, é a palavra chave with. Ela faz com que o compilador atribua à nova instância todos as propriedades que não forem declaradas em seu escopo.

Vejamos um exemplo:

public record Person(string Name, byte Age);

public static void Main()
{
    var john = new ("John", 30);
    var robert = john with { Name = "Robert" };
    Console.Write($"John's age: {john.Age}, Robert's age: {robert.Age}");
    //John's age: 30, Robert's age: 30
}

Repare que, no exemplo acima, john permanece inalterado e robert tem apenas seu nome atribuído, tendo como sua idade a mesma de john.

Considerações Finais

Imutabilidade é um recurso excelente para conter bugs por concorrência, a preocupação com gestão de estado, simplicidade, previsibilidade e legibilidade do código.

Essas vantagens tem um valor enorme e, ao mesmo tempo, os recursos oferecidos no C# permitem explorá-las com facilidade.

Recomendo muito considerar como ferramenta de design utilizando ao mesmo tempo como métrica de qualidade, porque se um dado objeto está sofrendo muitas mudanças é provável que sua forma de uso esteja inadequada.

Gostou? Deixe-me saber pelos indicadores. Tem dúvidas ou sugestões? Deixe um comentário ou me procure em minhas redes sociais.

Até a próxima!

Design - Toda regra tem uma exceção?

William Santos — Mon, 29 Apr 2024 13:10:46 +0000

Olá! Este é mais um post da seção Design e é, também, uma versão revisada do post Desempenho - Toda regra tem uma exceção?. No post sobre desempenho exploro a piora do desempenho ao empregar exceções em nosso código de forma indiscriminada, como um fator de validação de regras de negócio.

Neste pretendo abordar o tema exceções de forma mais ampla, explorando diferentes cenários onde exceções fazem ou não sentido.

Vamos lá!

Exceções: usar ou não?

Quando lemos a documentação da Microsoft sobre lançamento e tratamento de exceções (em inglês), encontramos os seguintes trechos (em tradução livre): "Uma exceção é qualquer condição de erro, ou comportamento inesperado, encontrada em um programa em execução. Exceções podem ser lançadas por conta de uma falha em seu código ou um código que você invoca (como em uma biblioteca compartilhada).
(...)
Sua aplicação pode se recuperar de algumas dessas condições mas de outras não. Embora você possa se recuperar da maioria das exceções de aplicação, você não pode da maioria das exceções do ambiente de execução. (...)
Exceções oferecem vantagens sobre outros métodos de notificação de erros, como códigos de retorno. Falhas não passam desapercebidas porque se uma exceção é lançada e você não a trata o ambiente de execução encerra sua aplicação. Valores inválidos não seguem propagando pelo sistema como resultado de um código de erro não identificado."

Fica claro que, a princípio, a Microsoft recomenda o uso de exceções. Certo?

Bom, mais ou menos.

Quando vemos a documentação sobre melhores práticas para exceções (em inglês), encontramos o seguinte trecho, também em tradução livre: "Uma classe pode prover métodos e propriedades que permitam evitar uma chamada que poderia resultar em uma exceção. Por exemplo, a classe FileStream fornece métodos que ajudam a determinar quando o final de um arquivo foi alcançado. Esses métodos podem ser usados para evitar uma exceção que seria lançada caso você tentasse ler além do fim do arquivo.
(...)
Outra forma de evitar exceções é retornando null (ou default) para a maioria dos casos de erro em vez de lançar uma exceção. Uma causa comum de erro pode ser considerada um fluxo normal. Retornando null nestes casos você reduz o impacto sobre o desempenho da aplicação."

Perceba aqui a preocupação com desempenho. É preferível buscar evitar exceções usando null, tendo como rede de proteção o possível lançamento de uma NullReferenceException, do que lançar uma exceção de aplicação.

Ou seja, exceções devem ser evitadas e, se usadas, que seja com moderação.

Parêntese: no post sobre desempenho mostro a diferença entre o retorno de um erro tipado e o lançamento de uma exceção. Fiz o mesmo experimento daquele post mas, agora, com o .NET 9 Preview 3. O resultado é o seguinte:

Ok. Mas agora você pode estar se perguntando: não devo usar exceções então?

Não é bem assim. Vejamos a seguir.

Cada caso é um caso (mas nem tanto)

Sendo bem direto, entendo existir um único caso onde usar exceções é um imperativo: ao desenvolver uma biblioteca. Isso por um motivo muito simples: exceções são a forma padrão de notificação de erros no .NET e, se cada biblioteca tiver seu próprio meio de notificação a aplicação pode ficar muito confusa e propensa a erros.

Entendo este caso como uma regra. Ou seja, não faz sentido empregar qualquer outro meio de notificação que não seja exceções. Um bom meio de observar isso é como o .NET funciona na interoperabilidade com componentes COM que, por natureza, retornam códigos de resultado (HRESULT). O ambiente de execução do .NET intercepta este código e, caso represente uma falha, lança uma exceção correspondente ao código de erro ou um COMException caso o código não lhe seja conhecido.

Sobre o null, não recomendo seu uso de forma alguma, e a Microsoft, mais recentemente, também não.
Sim, entendo que o doc tem um trecho dedicado a essa abordagem (e suspeito que esteja desatualizado) mas devemos nos lembrar sempre do Nullable Reference Types (em inglês) que é um mecanismo para evitarmos situações que lancem a famigerada NullReferenceException. Ou seja, não é uma boa ideia trabalhar com null como retorno. Aliás, há um termo, cunhado pelo próprio criador do null, Tony Hoare, que é o Erro de um Bilhão de Dólares (em inglês). Se o próprio criador do null o percebe como uma má ideia, faz sentido crer que seja mesmo!

Neste caso, precisamos de outra abordagem, que vamos tratar a seguir.

Impedindo Erros

Antes de mais nada precisamos entender que exceções são o meio mais seguro de notificar erros (não só no .NET mas imagino que em qualquer outro runtime).
Portanto, se você não se sente confortável para abrir mão delas, inclusive prefere sacrificar desepenho por essa segurança, é uma escolha legítima.
A intenção deste post é sugerir uma abordagem que, a partir das melhores práticas sugeridas pela própria Microsoft, permita não apenas ganho de desempenho como, também, um código mais semântico.

Vejamos como faze-lo.

Retornos Tipados

A Microsoft recomenda não utilizar códigos de erro pois uma falha em sua checagem pode resultar em um estado inválido da aplicação, o que é um risco tão real quanto sério. É aqui que a segurança oferecida pelas exceções se mostra útil e, também, onde a abordagem aqui sugerida demonstra seu valor.

A fim de evitar o retorno por código de erros é ideal que se utilize outros tipos de retorno, que demandem necessariamente uma checagem, para que o fluxo da aplicação possa seguir sem criar um estado inválido.
Dois exemplos são Option<T> e Result<TResult, TError> apresentados no post sobre Mônadas.

Option<T>

Option<T> é recomendado para métodos que precisam retornar um valor, como uma consulta ao banco de dados.
Considere o seguinte exemplo:

[HttpGet]
public IActionResult ById(Guid id)
{
    Option<User> user = userDataAccess.GetById(id);
    return user ? Ok(user) : NotFound();
}

Aqui, caso user não seja encontrado, retornamos um código 404 no método ById.
Mas vamos olhar mais de perto esse objeto de acesso a dados que é invocado:

public Option<User> GetById(Guid id)
{
    try
    {
        return context.Users.SingleOrDefault(u => u.Id == id).ToOption();
    }
    catch(Exception exc)
    {
        //Logs, métricas e outros tratamentos
        return Option.None<User>();
    }
}

Repare que, por estarmos na borda da aplicação, podemos tratar uma exceção imediatamente se necessário e simplesmente retornar um Option<T> com ausência de valor (None).
Essa simples medida já nos poupa a penalização de desempenho com a escalada da exceção pela pilha de chamadas (call stack). Ao mesmo tempo, na execução da consulta, é possível evitar o valor nulo invocando o método .ToOption() que o transformaria em um Option<User>.None.

Talvez você esteja se perguntando se o uso de Option<T> não seria análogo ao de null e a resposta é: sim e não. Sim porque é necessário um check para verificar se o valor existe para seguir com o fluxo caso os métodos próprios de Option<T> não sejam utilizados. E não porque o tipo de retorno deixa explícito que sempre haverá uma instância não nula como retorno, ainda que significando ausência de valor e, caso o desenvolvedor se esqueça de fazer a checagem, uma exceção de Option<T> a NoneValueException vai se encarregar de servir de rede de proteção para que o fluxo seja interrompido.

Nota: ao utilizar bibliotecas de terceiros, ou do framework que dependa de recursos do sistema, busque sempre utilizar um bloco try-catch (principalmente se não houver documentação). Tal como dito na nota acima, é a forma padrão de notificação do .NET e, portanto, é esperado que algum método venha a lançar alguma.

Para tratar eventuais nulos nesse tipo de componente, basta invocar o método desejado e adicionar .ToOption() para que o mesmo seja convertido para um Option<T>.

Result<TReturn, TError>

Aqui temos outro exemplo de como evitar exceções, desta vez em operações que podem retornar erros tipados que emulam as exceções de aplicação.

Considere o seguinte exemplo:

[HttpPost]
public IActionResult AddAddress(AddAddressRequest request)
{
    var result = Address.Create(request.Street, request.ZipCode);
    if(result)
        return Created(string.Empty, newAddress);

    return result switch
    {
        InvalidStreetError => "Invalid Street",
        InvalidZipCodeError => "Invalid ZipCode",
        _ => "Unspecified Error"
    };
}

Aqui temos uma tentativa de criação de endereço, que está sujeita a certas validações. Vamos ver no detalhe como isso acontece.

public class Address
{
    ...
    public static Result<Address, IAddressError> Create(string street, string zipCode)
    {
        if(string.IsNullOrEmpty(street))
            return AddressErrors.InvalidStreetError;
        if(string.IsNullOrEmpty(zipCode))
            return AddressErrors.InvalidZipCodeError;
        ...
        return address;
    }
}
...

public interface IAddressError {}
public struct InvalidStreetError : IAddressError {}
public struct InvalidZipCodeError : IAddressError {} 

public static class AddressErrors
{
    public InvalidStreetError InvalidStreetError => new InvalidStreetError();
    public InvalidZipCodeError InvalidZipCodeError => new InvalidZipCodeError();
}

Aqui vemos o método Create validando os dados de entrada para a criação de endereços. Caso haja algum erro é retornado um tipo equivalente e, do contrário, é retornado o novo endereço.

Desta forma, com um simples teste de resultado e um pattern matching, que simula um bloco try-catch, temos o que precisamos para decidir como seguir com o fluxo a partir de um sucesso ou erro.

Considerações Finais

Neste post entendemos como exceções de aplicação (chamadas de business exceptions no post original) não apenas prejudicam o desempenho como são desnecessárias e, por isso, devem ser evitadas a depender dos recursos disponíveis e pelo risco da applicação ser encerrada por força de uma exceção não tratada. Entendemos, também, como um antigo método de controle de fluxo, o retorno de null, não é desejável.

Para ter acesso aos tipos Option<T>, Result<TResult, TError> entre outros, te convido a conhecer o Moonad, uma biblioteca que escrevi a partir das mônadas do F# para facilitar seu uso no C#.

Gostou? Me deixe saber pelos indicadores. Fique à vontade para me procurar nas redes ou deixar comentários por aqui.

Muito obrigado pela leitura e até a próxima!

Forem: William Santos

Performance: Structs e Cópias (Defensivas)

Structs: Por quê?

Mas nem tudo são flores!

Cópias: o fundamental

O Modificador in

Cópias defensivas, uma (aparente) solução

Um pequeno exemplo

Readonly ao resgate!

Performance: medindo o impacto

Conclusão

Coopera Sharp - Chamadas em Sequência

O Problema

A Solução: Paralelismo!

Task.WhenAll

Parallel.ForEachAsync

Qual opção usar?

Conclusão

Coopera Sharp - Dependency Explosion

O Problema

Uma Solução Ingênua

Minha Solução (Elegante?)

Conclusão

Coopera Sharp - Otimização de Query

O Desafio

A Solução

Show me the Code

Conclusão

Crítica - MediatR: Pra Quê?

O que é o MediatR?

O Problema

Que Vantagem Maria Leva?

MediatR é de Fácil Replicação

Conclusão

Desempenho - Aprimorando Span com ZLinq

Motivação

Conclusão

Dica Rápida: Ganhando desempenho com o modificador Sealed

Conhecendo a palavra-chave sealed

Design: Event Sourcing (5 anos depois)

Antes de mais nada, muito obrigado!

Event Sourcing

Snapshots

Projeções

CQRS

Consistência

Conhecendo a aplicação

Introdução - Os fluxos

Parte 1 - Eventos

Parte 2 - EventStore

Parte 3 - Snapshot

Parte 4 - Projeções

Parte 5 - Juntando as peças

Vertical Slices

Conclusão

Playground: Jan Ken Po

Além do Código: Linguagem Ubíqua e Idioma do Código

O que é a Linguagem Ubíqua

A questão do idioma

Código em Inglês

Exemplos simples

Código Híbrido

Código em Português

Determinismo Organizacional

Conclusão

Design: Imutabilidade

O que é imutabilidade

Multi-threading e Paralelismo

Legibilidade, Debugging e Testes

Desempenho

Imutabilidade e C#

Readonly Structs

Records

Campos Read-only

Criando Novas Instâncias

Considerações Finais

Design - Toda regra tem uma exceção?

Exceções: usar ou não?

Cada caso é um caso (mas nem tanto)

Impedindo Erros

`Task.WhenAll`

`Parallel.ForEachAsync`

Imutabilidade e `C#`