Automapper e Mapster: Onde Usar e Onde Não Usar · carubbi

Ferramentas como Automapper e Mapster são amadas e odiadas em igual medida. Elas prometem eliminar o tédio de escrever código de mapeamento manual entre objetos — e cumprem essa promessa. Mas, como toda abstração poderosa, vêm com um custo: podem esconder decisões de design cruciais e corroer a clareza do seu modelo de domínio. Vamos entender quando elas são aliadas e quando se tornam inimigas, especialmente sob a ótica da Domain-Driven Design (DDD) e da Clean Architecture.

Onde Usar

1. Nas Bordas do Sistema

Automapper e Mapster brilham quando operam nas extremidades da aplicação, em pontos de comunicação com o mundo externo. Isso inclui:

Mapeamento entre DTOs (Data Transfer Objects) e View Models;
Transformação de dados entre camadas de apresentação e camadas de aplicação;
Conversão de objetos para transporte em APIs REST, mensageria ou persistência.

Esses são contextos onde o mapeamento é estrutural e não semântico — ou seja, quando você está apenas mudando a forma, não o significado dos dados.

Por exemplo:

// De um DTO vindo da API para um modelo de comando
var command = _mapper.Map<CreateOrderCommand>(request);

Nesses casos, a automação poupa tempo e reduz código repetitivo sem comprometer o entendimento do domínio.

2. Em Contextos de Leitura (Queries)

Em consultas — especialmente em arquiteturas CQRS (Command Query Responsibility Segregation) — é comum ter objetos simples representando resultados de leitura.

Aqui, o mapeamento automático pode transformar dados vindos do banco (ou de um ORM) em DTOs de resposta sem interferir na lógica de negócio.

var dto = _mapper.Map<OrderDto>(orderEntity);

Como não há invariantes ou regras de domínio envolvidas, o custo de abstração é pequeno e o ganho em produtividade é real.

Onde Não Usar

1. Dentro do Domínio

No coração do software — o modelo de domínio — Automapper e Mapster são perigosos.

O Domain-Driven Design enfatiza que o domínio deve expressar a linguagem ubíqua: o vocabulário compartilhado entre desenvolvedores e especialistas do negócio. Cada transformação entre objetos tem significado e intenção.

Mapear automaticamente OrderDto → Order pode parecer inofensivo, mas se o domínio impõe regras, invariantes ou cálculos derivados, o mapeamento automático ignora tudo isso — e cria bugs sutis.

// ERRADO: mapeando diretamente para o domínio
var order = _mapper.Map<Order>(dto); // pula regras de construção e invariantes

O correto seria expor um Factory ou método de criação explícito, preservando as regras do domínio:

var order = Order.Create(dto.CustomerId, dto.Items, clock.Now);

2. Entre Bounded Contexts

Em arquiteturas distribuídas ou microservices, cada Bounded Context (contexto delimitado) possui seu próprio modelo de domínio. Usar Automapper para converter automaticamente entre esses modelos quebra o isolamento entre contextos e dilui fronteiras conceituais.

Aqui, deve-se aplicar o padrão Anti-Corruption Layer (ACL) — uma camada de tradução manual e explícita. Cada transformação deve ser uma decisão consciente, não um reflexo automático.

3. Em Lógicas de Escrita (Commands)

Na parte de escrita do sistema, onde comandos alteram o estado do domínio, o mapeamento deve ser explícito e validado. Isso garante que a entrada seja interpretada corretamente, respeitando invariantes e regras de negócio.

Princípio Orientador

Automapper e Mapster devem servir à clareza, não escondê-la.

Robert C. Martin, em Clean Architecture, ensina que o domínio deve ser independente de frameworks. Isso vale também para bibliotecas de mapeamento. Elas podem viver nas camadas externas, Application ou Infrastructure, mas nunca no núcleo do domínio.

Ou, em termos práticos:

Use Automapper para economizar código. Não o use para economizar pensamento.

Conclusão

Automapper e Mapster são como facas de chef: afiadas, úteis e perigosas. Nas mãos certas, cortam a gordura do código boilerplate. Nas erradas, cortam a semântica do domínio.

Use-as:

Nas bordas do sistema (DTO ↔ ViewModel ↔ Response);
Em queries simples e operações de leitura.

Evite-as:

No domínio e entre contextos;
Em comandos que alteram estado de negócio;
Quando o mapeamento carrega significado, não apenas estrutura.

Em resumo, o valor dessas ferramentas está na automação consciente, aquela que respeita a arquitetura, o modelo de domínio e a linguagem que sustenta o negócio. Quando o código fala a língua do domínio, ele se torna mais do que software: torna-se conhecimento vivo.