Forem: Yuri Peixinho

ISP — Interface Segregation Principle (Princípio da Segregação de Interface)

Yuri Peixinho — Thu, 29 Jan 2026 21:42:18 +0000

Interface Segregation Principle

O ISP afirma que uma interface não deve forçar a classe a implementar métodos que elas não utilizam. A ideia é quebras grandes interfaces em menores e mais específicas, ou seja, em vez de interfaces gigantes e genéricas (”interfaces gordas”), devemos ter “interfaces magras”, quebradas e mais específicas.

“Clientes não devem ser forçados a depender de métodos que não usam.”

Pense nisso como um menu de restaurante:

Violação do ISP: O restaurante obriga você a comprar o combo com hambúrguer, batata, refrigerante, sorvete e café, mesmo que você só queira o hambúrguer
Aplicação do ISP: O menu é segregado. Você pode pedir itens individuais ou combos menores que façam sentido para o seu "apetite" (necessidade)

Exemplo didático do problema

Imagine que temos a Interface chamada ITrabalhador, ela possui métodos como Codificar(), Testar() e GerenciarProjetos().

Você vai criar uma classe chamada Programador que implementa essa interface. Até esse cenário tudo ocorre como o esperado.
O problema é que se você criar uma classe Gerente, e implementar a mesma interface ela será obrigada a implementar Codificar(), mesmo que o gerente não escreva código.

Essa prática cria um acoplamento desnecessário e “polui” o código com métodos vazios ou que lançam exceções como throw new NotImplementedException.

Exemplo técnico do problema

Vamos retomar o exemplo acima e desenvolver com o código com C# de duas formas, uma que viola o ISP e outra que não viola.

1. Violação estrutural

using System;

// Uma "Interface Gorda" que tenta fazer tudo
public interface ITrabalhador
{
    void Codificar();
    void Testar();
    void GerenciarProjeto();
}

public class Programador : ITrabalhador
{
    public void Codificar() => Console.WriteLine("Escrevendo código C#...");
    public void Testar() => Console.WriteLine("Testando bugs...");
    public void GerenciarProjeto() => Console.WriteLine("Atualizando o JIRA..."); 
    // Ok, talvez o programador faça um pouco de tudo.
}

public class Gerente : ITrabalhador
{
    public void Codificar()
    {
        // Oxente! O Gerente não deveria ser obrigado a ter este método.
        throw new NotImplementedException("Gerentes não codificam!");
    }

    public void Testar()
    {
        throw new NotImplementedException("Gerentes não testam!");
    }

    public void GerenciarProjeto() => Console.WriteLine("Gerenciando o time...");
}

2. O Jeito Correto

Agora, vamos segregar (separar) as interfaces. Assim, cada classe só assina o "contrato" que realmente consegue cumprir.

// Interfaces segregadas e específicas (Interfaces Magras)
public interface ICodificador
{
    void Codificar();
}

public interface ITestador
{
    void Testar();
}

public interface IGerente
{
    void GerenciarProjeto();
}

// O Programador implementa apenas o que faz sentido para ele
// Ele pode implementar múltiplas interfaces se necessário!
public class Programador : ICodificador, ITestador
{
    public void Codificar() => Console.WriteLine("Escrevendo código C#...");
    public void Testar() => Console.WriteLine("Testando bugs...");
}

// O Gerente agora está limpo e focado
public class Gerente : IGerente
{
    public void GerenciarProjeto() => Console.WriteLine("Gerenciando o time...");
}

LSP - Liskov Substitution Principle (Princípio da Substituição de Liskov)

Yuri Peixinho — Tue, 27 Jan 2026 01:41:36 +0000

O terceiro princípio é o Liskov Substituition Principle. Ele foi definido por Barbara Liskov em 1987 e, embora que por definição academia pareça ser um “bicho de setes cabeças”, na prática é bem simples e ideal para criar sistemas robustos.

O princípio diz que: Uma classe derivada deve poder ser substituída por sua classe base sem que o comportamento do programa seja alterado ou quebrado.

Para cumprir o príncpio pense assim: “O filho (classe que herda) deve conseguir fazer tudo que o pai (classe pai) prometeu que faria”. Se o pai diz "eu sei somar dois números", o filho não pode dizer "eu só sei somar se os números forem positivos". Isso seria uma surpresa desagradável para quem usa o código.

Analogia com Pássaros

Imagine que você tem um sistema para um zoológico.

Você cria a Entidade Passaro
Você define que todo Passaro tem a habilidade de voar.

Até aqui, tudo bem. Aí você cria os tipos específicos:

Pardal (É um Pássaro): Voa? Sim. ✅ (Tudo certo, segue o princípio).
Águia (É um Pássaro): Voa? Sim. ✅ (Tudo certo).

Agora vem o problema. Você precisa adicionar um Pinguim.

Pinguim (É um Pássaro): Voa? Não. ❌

Onde o princípio quebra?

Se você tem uma parte do seu código que diz: “Pegue todos os pássaros e faça-os voar”, quando chegar a vez do Pinguim o programa vai travar ou dar erro, porque pinguins não voam. Na aplicação promete que todo pássaro voa, mas o pinguim não cumpre essa promessa.

Como consertar o exemplo do Pinguim?

Em vez de colocar "Voar" na categoria principal Passaro, você deve criar uma categoria mais específica ou separar as habilidades:

Classe `Passaro` (Tem bico, bota ovos).
Classe PassaroQueVoa (Herda de Pássaro + sabe voar).
Classe PassaroQueNada Herda de Pássaro + sabe nadar).

Dessa forma o Pardal entra em PassaroQueVoa e o Peguim em PassaroQueNada

E o melhor: ninguém promete o que não pode cumprir, e o código não quebra.

Exemplo aplicado ao código

Vamos retomar o exemplo acima e desenvolver com o código com C# de duas formas, uma que viola o LSP e outra que não viola.

1. Violação Estrutural

Imagine que você tem uma classe abstrata Passaro. Em C#, é comum usarmos classes abstratas ou interfaces para definir contratos.

O exemplo abaixo viola o LSP porque o Pinguim não pode substituir Passaro sem causar efeitos colaterais (a exceção).

Classe Base

public abstract class Passaro
{
    public abstract void Voar();
}

Implementação Concreta

public class Pardal : Passaro
{
    public override void Voar()
    {
        Console.WriteLine("Pardal voando alto!");
    }
}

Implementação que viola o LSP

public class Pinguim : Passaro
{
    public override void Voar()
    {
        // O compilador obriga a implementar Voar(),
        // mas a lógica não permite. O dev lança uma exceção.
        throw new NotImplementedException("Pinguins não voam!");
    }
}

2. O Jeito Correto

Em C#, a melhor forma de resolver isso é segregando as capacidades através de Interfaces. Nem todo pássaro é um IVoador.

Essa implementação abaixo torna impossível passar um Pinguim para um método que espera IVoador. O compilador do C# vai te impedir antes mesmo de você rodar o programa.

Definição de abstração (interface e classe abstrata)

// Define apenas o que é comum a TODOS
public abstract class Ave 
{
    public void Comer() { Console.WriteLine("Comendo..."); }
}

// Interface (Capacidade) separada
public interface IVoador
{
    void Voar();
}

Implementações

// Pardal é uma Ave E sabe voar
public class Pardal : Ave, IVoador
{
    public void Voar() 
    { 
        Console.WriteLine("Pardal voando!"); 
    }
}

// Pinguim é apenas uma Ave (não implementa IVoador)
public class Pinguim : Ave 
{
    // Pode ter métodos de nadar aqui
}

OCP — Open/Closed Principle (Princípio Aberto/Fechado)

Yuri Peixinho — Mon, 26 Jan 2026 23:58:55 +0000

Princípio Aberto/Fechado

Esse é o segunda pilar do SOLID. Sua fundamentação existe para que os softwares criados sejam fáceis de manter e evoluir sem quebrar o que já funciona.

Certo! Mas o que diabos isso significa? Os sistemas não são estáticos, eles tendem a evoluír. O cenário comum no mercado, portanto, é: com novas definições de funcionalidades os desenvolvedores geralmente alteram o código-fonte existente, código este, que já foi testado e homologado. Resultando em um sistema difícil de manter e “sustentar”.

O OCP surge para mitigar esse problema e a definição foi criada por Bertrand Meyer:

"Entidades de software (classes, módulos, funções, etc.) devem estar abertas para extensão, mas fechadas para modificação."

Aberto pra Extensão: Você é deve ser capaz de adicionar novos comportamentos e funcionalidades ao sistema à medida que os requisitos mudam.

Fechada para Modificações: Ao adicionar essa nova funcionalidade, você não deve alterar o código-fonte existente que já foi estado e está funcionando

Metáfora da Tomada

Tenho um professor que comparou esse princípio com uma tomada. elétrica de parede.

Ela é fechada pra modificação, já que você não precisa quebrar a parede e refazer a fiação elétrica da casa toda vez que compra um novo eletrodoméstico
Ela é abertura para extensão, você pode instalar uma TV, ventilador ou carregador estendendo a utilidade daquela rede relétrica, apenas plugando algo novo. A interface (os buracos da tomada) permitee isso.

Exemplo prático

Vamos desenvolver um cálculo de Bônus Anual. Imagine uma classe CalculadoraDeBonus. Inicialmente, a empresa só tem "Desenvolvedores" e "Gerentes".

Exemplo Ruim (Violando OCP)

Nesta abordagem comum (mas ruim), usamos um switch ou if/else para verificar o cargo. O problema: quero adicionar dois novos cargos, diretor e estagiário. Para isso eu preciso abrir a classe e modificá-la diretamente! Isso viola o OCP

public class CalculadoraDeBonus
{
    public decimal Calcular(string cargo, decimal salario)
    {
        if (cargo == "Gerente")
        {
            return salario * 0.2m; 
        }
        else if (cargo == "Desenvolvedor")
        {
            return salario * 0.1m; 
        }

        // Se a empresa criar o cargo "Diretor" amanhã, 
        // VOU TER QUE ALTERAR ESTE ARQUIVO.
        return 0;
    }
}

O Risco: Ao editar esse arquivo para adicionar o "Diretor", você pode sem querer apagar uma linha ou mudar a lógica do "Gerente", causando bugs em algo que já estava testado.

Solução (Aplicando OCP)

Vou trazer duas abordagens para fechar a classe para modificação e abri-las para extensão. Ambas abordagens resolvem o OCP, mas elas comunicam intenções diferentes sobre o seu sistema.

Abordagem com Classe Abstrata
Abordagem com Interfaces

1. Abordagem com Classe Abstrata

Use essa abrodagem quando existe uma relação forte de herança e você quer reaproveitar propriedades ou métodos

Cenário: Todo funcionário tem Nome e Salario (código compartilhado), mas o cálculo do bônus muda.

Contrato

public abstract class FuncionarioBase
{
    // Código compartilhado (Reuso)
    public string Nome { get; set; }
    public decimal Salario { get; set; }

    // Obriga as classes filhas a implementarem a lógica específica
    public abstract decimal CalcularBonus();

    // Método comum que já funciona para todos (não precisa sobrescrever)
    public string ObterCracha() => $"Funcionário: {Nome}";
}

Aberto para extensões:

public class Gerente : FuncionarioBase
{
    public override decimal CalcularBonus()
    {
        return Salario * 0.2m;
    }
}

public class Desenvolvedor : FuncionarioBase
{
    public override decimal CalcularBonus()
    {
        return Salario * 0.1m;
    }
}

Uso


public void Processar(FuncionarioBase funcionario) 
{
    Console.WriteLine(funcionario.CalcularBonus()); 
}

2. Abordagem com Interface

Use esta abordagem quando o foco é o "O QUE FAZ" (Comportamento). Interfaces são contratos puros. Elas não carregam "bagagem" (estado ou variáveis) e permitem maior flexibilidade, pois uma classe pode implementar múltiplas interfaces.
Cenário: Aqui não nos importamos se é um funcionário, um prestador de serviço ou um robô. Só nos importamos se ele tem uma regra de bônus. Isso é frequentemente chamado de Strategy Pattern.

Contrato

// --- O Contrato (Interface) ---
public interface IRegraDeBonus
{
    decimal Calcular(decimal salarioBase);
}

public class BonusParaDesenvolvedor : IRegraDeBonus
{
    public decimal Calcular(decimal salarioBase)
    {
        return salarioBase * 0.1m;
    }
}

Aberto para extensões:


// Note que não herdamos de ninguém, apenas assinamos o contrato
public class BonusParaGerente : IRegraDeBonus
{
    public decimal Calcular(decimal salarioBase)
    {
        return salarioBase * 0.2m;
    }
}

Uso

public class CalculadoraServico
{
    // Recebemos a INTERFACE. Baixíssimo acoplamento.
    public decimal ExecutarCalculo(decimal salario, IRegraDeBonus regra)
    {
        return regra.Calcular(salario);
    }
}

Comparação entre abordagens: Abstract Class vs. Interface

Característica	Abstract Class	Interface
Relacionamento	"É um" (Hierarquia estrita). Um Gerente é um Funcionário.	"Faz isso" (Capacidade). Essa classe sabe calcular bônus.
Reuso de Código	Alto. Permite compartilhar propriedades (`Nome`, `ID`) e métodos concretos.	Baixo/Nenhum. Apenas define as assinaturas dos métodos.*
Herança	Limitada. C# só permite herdar de 1 classe. Se usar Abstract, você "gasta" essa cartada.	Múltipla. Uma classe pode implementar 5 interfaces diferentes (`IBonificavel`, `IAutenticavel`, etc).
Acoplamento	Médio. As filhas dependem da classe pai.	Baixíssimo. As classes só dependem do contrato.
Quando usar no OCP?	Quando você tem uma família de objetos intimamente relacionados que compartilham estrutura.	Quando você quer plugar comportamentos diferentes (Strategy Pattern) ou testabilidade máxima (Mocks).

No desenvolvimento moderno de C# (.NET Core/Dependency Injection), Interfaces são usadas em 90% dos casos para garantir o OCP, pois facilitam muito os testes unitários (Mocking).

SRP — Single Responsibility Principle (Princípio da Responsabilidade Única)

Yuri Peixinho — Mon, 26 Jan 2026 23:36:18 +0000

Single Responsability Principle

Esse é o primeiro pilar do SOLID. A definição clássica é “Uma classse deve ter um, e apenas um motivo pra mudar.”.

Na prática, isso quer dizer que uma classe deve ser responsável por uma funcionalidade/parte específica do software. Em sistemas “blocos de cimentos”, é comum encontrarmos as chamadas “God Objects” (Objeto Deus), uma classe gigantesca que sabem e fazem tudo. O que contradiz o princípio da responsabilidade única.

Analogia

Imagine um funcionário de um restaurante que é, ao mesmo tempo, o cozinheiro, o garçom e o faxineiro . Se ele precisar mudar a forma como limpa o chão, o serviço de cozinha e o atendimento podem ser afetados ou interrompidos. No SRP, dividimos essas tarefas entre especialistas para que um não atrapalhe a evolução do outro.

Exemplo

Vamos imaginar um cenário em que o princípio não foi aplicado e após isso vamos transformá-lo em um código modular. Imagine um sistema que gerencia pedidos de e-commerce.

Exemplo Problema

Na classe Pedido abaixo, temos três motivos diferentes para serem alterados. Se a regra de calculo, banco e e-mail mudar. Cada método representa uma responsabilidade diferente para a classe Pedido

class Pedido:
    def calcular_total(self):
        # Lógica de negócio (Preço, impostos, descontos)
        pass

    def salvar_no_banco(self):
        # Lógica de infraestrutura (Conexão SQL, tabelas)
        pass

    def enviar_email_confirmacao(self):
        # Lógica de comunicação (Servidor SMTP, template do e-mail)
        pass

Exemplo Solução

Para aplicar o SRP, separamos as tarefas em “especialistas”. Cada classe agora tem apenas uma razão para existir e mudar.

Pedido vai conter apenas a lógica de cálculo calcular_total
salvar_no_banco vai ser uma nova classe chamada PedidoRepository, que vai implementar o Padrão Repository
enviar_email_confirmacao vai ser um serviço separado apenas por enviar comunicações

Desse modo, se você decidir trocar o e-mail por uma mensagem no WhatsApp, você altera apenas o serviço respectivo. A regra de cálculo do Pedido então permanece segura e intocada, como uma peça LEGO independente

Exemplo aplicado a contexto: Clean Architecture, Mediator, CQRS e DDD

Veja como o SRP se manifesta em um CommandHandler usando Mediator:

// Este Handler tem UMA única razão para mudar: 
// Se o fluxo de "Criação de Pedido" for alterado.
public class CriarPedidoHandler : IRequestHandler<CriarPedidoCommand, Guid>
{
    private readonly IPedidoRepository _repository; // Interface (DIP)
    private readonly IMediator _mediator;

    public async Task<Guid> Handle(CriarPedidoCommand request, CancellationToken ct)
    {
        // 1. Regra de Negócio (DDD: Entidade decide se pode ser criada)
        var pedido = new Pedido(request.ClienteId, request.Itens);

        // 2. Persistência (Clean Arch: O Handler não sabe se é SQL ou NoSQL)
        await _repository.SalvarAsync(pedido);

        // 3. Comunicação (Mediator: Dispara um evento para quem interessar)
        // Isso separa a criação do pedido do envio de e-mail (SRP puro!)
        await _mediator.Publish(new PedidoCriadoEvent(pedido.Id));

        return pedido.Id;
    }

Veja o conteúdo completo aqui!

Princípios SOLID

Yuri Peixinho — Fri, 23 Jan 2026 01:57:50 +0000

Contexto do SOLID

Antigamente os sistemas eram desenvolvidos com um único objetivo: fazer o software funcionar. Os padrões utilizados eram monolíticos e rígidos, com forte acoplamento e com tudo interligado. Atualmente sistemas conhecidos como “Código espaguete” ou “Grande Bola de Lama”. Como tudo estava interligado, corrigir um erro em uma ponta do sistema geralmente causava erros em outras partes do sistema.

Crise do Software

Na década de 70 e 80 o desenvolvimento de software enfrentava uma crise. O hardware estava ficando incrivelmente potente e barato, mas o software estava se tornando tão complexo que as equipes não conseguiam mantê-los de forma eficiente.

Introdução ao SOLID

O SOLID veio pra transformar o desenvolvimento de software em uma tarefa artesanal em uma engenharia, focada em criar peças que se encaixam sem estarem “soldadas” umas nas outras. Ele é um conjunto de cinco princípios de design de software para a programação orientada a objetos (POO).

Em resumo, podemos dizer que os princípios funcionam como uma base/guia para os desenvolvedores arquitetarem soluções fáceis de manter, testar e evoluír ao longo do tempo.

Ao invés de desenvolvermos sistemas como “um grande bloco de cimento”, o SOLID nos ensina a construir softwares como peças “LEGO”, que se encaixam de forma inteligente.

1. Princípio da Responsabilidade Única

Esse é o primeiro pilar do SOLID. A definição clássica é “Uma classse deve ter um, e apenas um motivo pra mudar.”.

Analogia

Exemplo

Vamos imaginar um cenário em que o princípio não foi aplicado e após isso vamos transformá-lo em um código modular. Imagine um sistema que gerencia pedidos de e-commerce.

Exemplo Problema

class Pedido:
    def calcular_total(self):
        # Lógica de negócio (Preço, impostos, descontos)
        pass

    def salvar_no_banco(self):
        # Lógica de infraestrutura (Conexão SQL, tabelas)
        pass

    def enviar_email_confirmacao(self):
        # Lógica de comunicação (Servidor SMTP, template do e-mail)
        pass

Exemplo Solução

Para aplicar o SRP, separamos as tarefas em “especialistas”. Cada classe agora tem apenas uma razão para existir e mudar.

Pedido vai conter apenas a lógica de cálculo calcular_total
salvar_no_banco vai ser uma nova classe chamada PedidoRepository, que vai implementar o Padrão Repository
enviar_email_confirmacao vai ser um serviço separado apenas por enviar comunicações

Exemplo aplicado a contexto: Clean Architecture, Mediator, CQRS e DDD

Veja como o SRP se manifesta em um CommandHandler usando Mediator:

// Este Handler tem UMA única razão para mudar: 
// Se o fluxo de "Criação de Pedido" for alterado.
public class CriarPedidoHandler : IRequestHandler<CriarPedidoCommand, Guid>
{
    private readonly IPedidoRepository _repository; // Interface (DIP)
    private readonly IMediator _mediator;

    public async Task<Guid> Handle(CriarPedidoCommand request, CancellationToken ct)
    {
        // 1. Regra de Negócio (DDD: Entidade decide se pode ser criada)
        var pedido = new Pedido(request.ClienteId, request.Itens);

        // 2. Persistência (Clean Arch: O Handler não sabe se é SQL ou NoSQL)
        await _repository.SalvarAsync(pedido);

        // 3. Comunicação (Mediator: Dispara um evento para quem interessar)
        // Isso separa a criação do pedido do envio de e-mail (SRP puro!)
        await _mediator.Publish(new PedidoCriadoEvent(pedido.Id));

        return pedido.Id;
    }

2. Princípio Aberto/Fechado

Esse é o segunda pilar do SOLID. Sua fundamentação existe para que os softwares criados sejam fáceis de manter e evoluir sem quebrar o que já funciona.

O OCP surge para mitigar esse problema e a definição foi criada por Bertrand Meyer:

"Entidades de software (classes, módulos, funções, etc.) devem estar abertas para extensão, mas fechadas para modificação."

Aberto pra Extensão: Você é deve ser capaz de adicionar novos comportamentos e funcionalidades ao sistema à medida que os requisitos mudam.

Fechada para Modificações: Ao adicionar essa nova funcionalidade, você não deve alterar o código-fonte existente que já foi estado e está funcionando

Metáfora da Tomada

Tenho um professor que comparou esse princípio com uma tomada. elétrica de parede.

Ela é fechada pra modificação, já que você não precisa quebrar a parede e refazer a fiação elétrica da casa toda vez que compra um novo eletrodoméstico
Ela é abertura para extensão, você pode instalar uma TV, ventilador ou carregador estendendo a utilidade daquela rede relétrica, apenas plugando algo novo. A interface (os buracos da tomada) permitee isso.

Exemplo prático

Vamos desenvolver um cálculo de Bônus Anual. Imagine uma classe CalculadoraDeBonus. Inicialmente, a empresa só tem "Desenvolvedores" e "Gerentes".

Exemplo Ruim (Violando OCP)

public class CalculadoraDeBonus
{
    public decimal Calcular(string cargo, decimal salario)
    {
        if (cargo == "Gerente")
        {
            return salario * 0.2m; 
        }
        else if (cargo == "Desenvolvedor")
        {
            return salario * 0.1m; 
        }

        // Se a empresa criar o cargo "Diretor" amanhã, 
        // VOU TER QUE ALTERAR ESTE ARQUIVO.
        return 0;
    }
}

O Risco: Ao editar esse arquivo para adicionar o "Diretor", você pode sem querer apagar uma linha ou mudar a lógica do "Gerente", causando bugs em algo que já estava testado.

Solução (Aplicando OCP)

Vou trazer duas abordagens para fechar a classe para modificação e abri-las para extensão. Ambas abordagens resolvem o OCP, mas elas comunicam intenções diferentes sobre o seu sistema.

Abordagem com Classe Abstrata
Abordagem com Interfaces

Abordagem com Classe Abstrata

Use essa abrodagem quando existe uma relação forte de herança e você quer reaproveitar propriedades ou métodos

Cenário: Todo funcionário tem Nome e Salario (código compartilhado), mas o cálculo do bônus muda.

Contrato

public abstract class FuncionarioBase
{
    // Código compartilhado (Reuso)
    public string Nome { get; set; }
    public decimal Salario { get; set; }

    // Obriga as classes filhas a implementarem a lógica específica
    public abstract decimal CalcularBonus();

    // Método comum que já funciona para todos (não precisa sobrescrever)
    public string ObterCracha() => $"Funcionário: {Nome}";
}

Aberto para extensões:

public class Gerente : FuncionarioBase
{
    public override decimal CalcularBonus()
    {
        return Salario * 0.2m;
    }
}

public class Desenvolvedor : FuncionarioBase
{
    public override decimal CalcularBonus()
    {
        return Salario * 0.1m;
    }
}

Uso


public void Processar(FuncionarioBase funcionario) 
{
    Console.WriteLine(funcionario.CalcularBonus()); 
}

Abordagem com Interface

Contrato

// --- O Contrato (Interface) ---
public interface IRegraDeBonus
{
    decimal Calcular(decimal salarioBase);
}

public class BonusParaDesenvolvedor : IRegraDeBonus
{
    public decimal Calcular(decimal salarioBase)
    {
        return salarioBase * 0.1m;
    }
}

Aberto para extensões:


// Note que não herdamos de ninguém, apenas assinamos o contrato
public class BonusParaGerente : IRegraDeBonus
{
    public decimal Calcular(decimal salarioBase)
    {
        return salarioBase * 0.2m;
    }
}

Uso

public class CalculadoraServico
{
    // Recebemos a INTERFACE. Baixíssimo acoplamento.
    public decimal ExecutarCalculo(decimal salario, IRegraDeBonus regra)
    {
        return regra.Calcular(salario);
    }
}

Comparação entre abordagens: Abstract Class vs. Interface

Característica	Abstract Class	Interface
Relacionamento	"É um" (Hierarquia estrita). Um Gerente é um Funcionário.	"Faz isso" (Capacidade). Essa classe sabe calcular bônus.
Reuso de Código	Alto. Permite compartilhar propriedades (`Nome`, `ID`) e métodos concretos.	Baixo/Nenhum. Apenas define as assinaturas dos métodos.*
Herança	Limitada. C# só permite herdar de 1 classe. Se usar Abstract, você "gasta" essa cartada.	Múltipla. Uma classe pode implementar 5 interfaces diferentes (`IBonificavel`, `IAutenticavel`, etc).
Acoplamento	Médio. As filhas dependem da classe pai.	Baixíssimo. As classes só dependem do contrato.
Quando usar no OCP?	Quando você tem uma família de objetos intimamente relacionados que compartilham estrutura.	Quando você quer plugar comportamentos diferentes (Strategy Pattern) ou testabilidade máxima (Mocks).

No desenvolvimento moderno de C# (.NET Core/Dependency Injection), Interfaces são usadas em 90% dos casos para garantir o OCP, pois facilitam muito os testes unitários (Mocking).

3. Princípio da Substituição de Liskov

O princípio estabelece que uma classe derivada deve poder substituir sua classe base sem alterar ou comprometer o comportamento esperado do programa. Em outras palavras, ao herdar a classe B a partir da classe A, o desenvolvedor deve conseguir realizar tudo o que era possível com A utilizando B, mantendo as mesmas garantias de funcionamento e, se necessário, acrescentando novos comportamentos, mas nunca removendo ou quebrando os existentes.

Analogia com Pássaros

Imagine que você tem um sistema para um zoológico.

Você cria a Entidade Passaro
Você define que todo Passaro tem a habilidade de voar.

Até aqui, tudo bem. Aí você cria os tipos específicos:

Pardal (É um Pássaro): Voa? Sim. ✅ (Tudo certo, segue o princípio).
Águia (É um Pássaro): Voa? Sim. ✅ (Tudo certo).

Agora vem o problema. Você precisa adicionar um Pinguim.

Pinguim (É um Pássaro): Voa? Não. ❌

Onde o princípio quebra?

Como consertar o exemplo do Pinguim?

Em vez de colocar "Voar" na categoria principal Passaro, você deve criar uma categoria mais específica ou separar as habilidades:

Classe `Passaro` (Tem bico, bota ovos).
Classe PassaroQueVoa (Herda de Pássaro + sabe voar).
Classe PassaroQueNada Herda de Pássaro + sabe nadar).

Dessa forma o Pardal entra em PassaroQueVoa e o Peguim em PassaroQueNada

E o melhor: ninguém promete o que não pode cumprir, e o código não quebra.

Exemplo aplicado ao código

Vamos retomar o exemplo acima e desenvolver com o código com C# de duas formas, uma que viola o LSP e outra que não viola.

Violação Estrutural

Imagine que você tem uma classe abstrata Passaro. Em C#, é comum usarmos classes abstratas ou interfaces para definir contratos.

O exemplo abaixo viola o LSP porque o Pinguim não pode substituir Passaro sem causar efeitos colaterais (a exceção).

Classe Base

public abstract class Passaro
{
    public abstract void Voar();
}

Implementação Concreta

public class Pardal : Passaro
{
    public override void Voar()
    {
        Console.WriteLine("Pardal voando alto!");
    }
}

Implementação que viola o LSP

public class Pinguim : Passaro
{
    public override void Voar()
    {
        // O compilador obriga a implementar Voar(),
        // mas a lógica não permite. O dev lança uma exceção.
        throw new NotImplementedException("Pinguins não voam!");
    }
}

O Jeito Correto

Em C#, a melhor forma de resolver isso é segregando as capacidades através de Interfaces. Nem todo pássaro é um IVoador.

Essa implementação abaixo torna impossível passar um Pinguim para um método que espera IVoador. O compilador do C# vai te impedir antes mesmo de você rodar o programa.

Definição de abstração (interface e classe abstrata)

// Define apenas o que é comum a TODOS
public abstract class Ave 
{
    public void Comer() { Console.WriteLine("Comendo..."); }
}

// Interface (Capacidade) separada
public interface IVoador
{
    void Voar();
}

Implementações

// Pardal é uma Ave E sabe voar
public class Pardal : Ave, IVoador
{
    public void Voar() 
    { 
        Console.WriteLine("Pardal voando!"); 
    }
}

// Pinguim é apenas uma Ave (não implementa IVoador)
public class Pinguim : Ave 
{
    // Pode ter métodos de nadar aqui
}

4. Principio da Segragação de Interface

“Clientes não devem ser forçados a depender de métodos que não usam.”

Pense nisso como um menu de restaurante:

Violação do ISP: O restaurante obriga você a comprar o combo com hambúrguer, batata, refrigerante, sorvete e café, mesmo que você só queira o hambúrguer
Aplicação do ISP: O menu é segregado. Você pode pedir itens individuais ou combos menores que façam sentido para o seu "apetite" (necessidade)

Exemplo didático do problema

Imagine que temos a Interface chamada ITrabalhador, ela possui métodos como Codificar(), Testar() e GerenciarProjetos().

Você vai criar uma classe chamada Programador que implementa essa interface. Até esse cenário tudo ocorre como o esperado.
O problema é que se você criar uma classe Gerente, e implementar a mesma interface ela será obrigada a implementar Codificar(), mesmo que o gerente não escreva código.

Essa prática cria um acoplamento desnecessário e “polui” o código com métodos vazios ou que lançam exceções como throw new NotImplementedException.

Exemplo técnico do problema

Vamos retomar o exemplo acima e desenvolver com o código com C# de duas formas, uma que viola o ISP e outra que não viola.

1. Violação estrutural

using System;

// Uma "Interface Gorda" que tenta fazer tudo
public interface ITrabalhador
{
    void Codificar();
    void Testar();
    void GerenciarProjeto();
}

public class Programador : ITrabalhador
{
    public void Codificar() => Console.WriteLine("Escrevendo código C#...");
    public void Testar() => Console.WriteLine("Testando bugs...");
    public void GerenciarProjeto() => Console.WriteLine("Atualizando o JIRA..."); 
    // Ok, talvez o programador faça um pouco de tudo.
}

public class Gerente : ITrabalhador
{
    public void Codificar()
    {
        // Oxente! O Gerente não deveria ser obrigado a ter este método.
        throw new NotImplementedException("Gerentes não codificam!");
    }

    public void Testar()
    {
        throw new NotImplementedException("Gerentes não testam!");
    }

    public void GerenciarProjeto() => Console.WriteLine("Gerenciando o time...");
}

2. O Jeito Correto

Agora, vamos segregar (separar) as interfaces. Assim, cada classe só assina o "contrato" que realmente consegue cumprir.

// Interfaces segregadas e específicas (Interfaces Magras)
public interface ICodificador
{
    void Codificar();
}

public interface ITestador
{
    void Testar();
}

public interface IGerente
{
    void GerenciarProjeto();
}

// O Programador implementa apenas o que faz sentido para ele
// Ele pode implementar múltiplas interfaces se necessário!
public class Programador : ICodificador, ITestador
{
    public void Codificar() => Console.WriteLine("Escrevendo código C#...");
    public void Testar() => Console.WriteLine("Testando bugs...");
}

// O Gerente agora está limpo e focado
public class Gerente : IGerente
{
    public void GerenciarProjeto() => Console.WriteLine("Gerenciando o time...");
}

5. Princípio da Inversão de Dependência

A definição formal do quinto princípio parece um pouco técnica:

“Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstraçãoes”.

O conceito de Dependency Inversion (DI) pode deixar desenvolvedores imaturos confuso, isso porque esse conceito geralmente surge de uma necessidade prática e real e as explicações geralmente possuem níveis de abstrações que exiga a compreensão por completo do fluxo de um sistema. Antes de entendermos sobre o assunto temos que entender o que são os módulos de baixo e alto nível de um sistema

Módulos de alto e baixo nível

Entender como o sistema de comporta em níveis de módulos e a relação entre eles é de extrema importância para a compreensão do conceito de DI.

Alto nível

O foco aqui é a regra de negócio, lógica central, é aqui que existe o “valor” do que é o sistema. Deve ser algo estável e mudar pouco. Por exemplo: calcular o frete de um pedido, gerar uma fatura ou processar um pagamento.

Baixo nível

O foco é os detalhes de implementação, mecanismos concretos. São os braços e as pernas que executam o que é demandado pelo módulo de alto nível, mas não definem as regras. Isto posto, está mais sujeito a mudanças e alguns exemplos são: bancos de dados específicos, frameworks de interfaces, etc…

Relação entre alto e baixo nível

De forma resumida, podemos dizer que:

Alto nível = o que o sistema faz (regras de negócio).

Baixo nível = como o sistema faz (detalhes técnicos).

Abstração = a ponte que une os dois, mantendo o alto nível protegido dos detalhes.

Didaticamente explicando o conceito:

O alto nível diz: “Preciso calculas fretes”
O baixo nível responde: “Ok, sei falar com os Correios e calcular o valor”

Se o alto nível depender diretamente dos detalhes (Correios), ele fica preso apenas a um serviço, então se amanhã mudar para FedEx, a alteração deverá ser feita na alta escala do sistema (alto nível), o que é uma péssima prática.

Para resolver a problemática acima, podemos utilizar a seguinte abordagem:

O alto nível só conhece a regra “alguém que calcule frete”
O desenvolvedor cria a abstração ICalculadoraFrete
O baixo nível (Correios ou FedEx) implementa essa abstração
O alto nível não precisa mudar quando trocarmos serviço postal

Inversão de dependência

A ideia central da inversão de dependência é “desamarrar” as regras de negócios a um detalhe específico de implementação. Já que essa prática deixa o sistema rígido e difícil de mudar.

Analogia do dia a dia

Sem DI: Um carro que só funciona se você abastecer com a gasolina da “Bandeira X”
Com DI: O carro depende apenas da abstação (interface) “combustível líquido inflamável”
- Pode ser gasolina comum, aditivada, etanol ou até biocombustível

Com base na analogia acima, a gente é capaz de perceber que com a Inversão de dependência o carro não se prende aos detalhe da gasolina (baixo nível), ele só depende da abstração de um combustível

Aplicando o princípio da Inversão de Dependência

Para utilizar a inversão de dependência vamos aplicar a Inversão de Controle (IoC) e Injeção de Dependência (DI)

1. Criamos uma interface (um contrato)

public interface INotificacaoService
{
    void Enviar(string mensagem);
}

Aqui estamos dizendo: "Eu não me importo como a mensagem será enviada. Só quero que exista alguém capaz de executar o método Enviar()." Isso é lindo. Porque o PedidoService não quer saber de e-mail, SMS, WhatsApp, sinal de fumaça... ele só quer enviar.

2. Criamos implementações dessa interface

Enviar por E-mail:

public class EmailService : INotificacaoService
{
    public void Enviar(string mensagem)
    {
        Console.WriteLine("Enviando Email: " + mensagem);
    }
}

3. PedidoService não se importa mais com o como

Agora ele só recebe a dependência via construtor:

public class PedidoService
{
    private readonly INotificacaoService _notificacaoService;

    // INJEÇÃO DE DEPENDÊNCIA VIA CONSTRUTOR
    public PedidoService(INotificacaoService notificacaoService)
    {
        _notificacaoService = notificacaoService;
    }

    public void FinalizarPedido()
    {
        _notificacaoService.Enviar("Pedido finalizado!");
    }
}

Deploy: Cenário: Azure App Service + Github + SQL Server

Yuri Peixinho — Thu, 08 Jan 2026 23:07:31 +0000

Introdução

Deploy não é um botão. É um processo consciente de levar software para o mundo real. Geralmente quando não temos conhecimento sobre os processos de deploy ficamos com algumas questões pendentes em nossa mente:

Onde o código roda?
Como ele chega lá?
Como ele acessa o banco?
Como configuro sem expor segredo (secret)?
Como atualizo sem quebrar tudo?

Vamos passar por todo esse processo com aplicação em um cenário real.

As peças do cenário que vamos montar

Azure App Service: onde a aplicação roda
Github: onde seu código vive
Github Actions (opcional, mas recomendado): automação de build e deploy
Azure SQL Database (SQL Server): onde seus dados ficam

GitHub (código)
↓
Pipeline (build / deploy)
↓
Azure App Service (API / App)
↓
Azure SQL Database (dados)

1. O que é o Azure App Service?

Como já vimos nos tipos de servidores, podemos dizer que o Azure Service é um serviço gerenciado. Isso significa que você:

Não cria servidor
Não instala Windows/Linux
Configura IIS, Kestrel, Nginx manualmente

1.1 App Service

A plataforma Azure cuida de todas essas questões pra você e quando você cria um App Service, você está definindo

Runtime (ex: .NET 8)
Plano de hospedagem (CPU / memória / custo)
Região (onde o servidor fica)

Que resulta em uma URL pública e um ambiente pronto pra a execução do seu código:

https://minha-api.azurewebsites.net

Nesse momento, não tem código nenhum rodando ainda.

1.2 Como o código chega na Azure? (Github Actions)

Após a configuração do Azure App Service ser concluída precisamos efetivamente subir o nosso código de um determinado repositório para o Azure. Em nossa abordagem vamos utilizar o Github Actions e entender o problema que ele resolve.

1.1.1 Processo manual

Antes do Github Actions, o deploy normalmente era assim:

O desenvolvedor faz o seguinte processo:

Compila local
Publica manualmente
Sobre arquivo por FTP

Esse processo gera problemas como inconsistência, erro humano, falta de histórico e deploys imprevisíveis

1.1.2 Github Actions

Podemos dizer que o GitHub Actions é um robô configurável que roda dentro do GitHub sempre que algo acontece no repositório.

Esse “algo” pode ser:

push
pull request
criação de tag
horário agendado

Esse robô pode compilar código, rodar testes, gerar build, fazer deploy, enviar notificações, etc. Isso tudo só acontece porque um workflow é configurado.

1.3 O que é um workflow e o que ele tem a ver com tudo isso?

Um workflow é um arquivo .yml que diz sugere: “Quando X acontecer, execute Y passos nessa ordem”, então, por exemplo:

SE alguém fizer push na branch main
ENTÃO:
  - compile
  - teste
  - publique
  - faça deploy

E esse arquivo fica em:

.github/workflows/deploy.yml

Esse arquivo é código, portanto, o Deploy passa a ser versionado, auditável e repetível.

2. Criando o SQL Server no Azure

Ao criar um banco de dados no Azure, você já vai ter backup automático, alta disponibilidade e sem precisar instalar nada.

Ao final do processo você vai ter o nome do servidor, nome do banco, usuário e senha. Essas informações nunca deve ir no código.

Quando você cria o Azure SQL Database, o Azure cria duas coisas:

2.1 Servidor Lógico (SQL Server)

Não é uma VM (Virtual Machine) e sim um endpoint gerenciado para autenticação e conexões. Esse servidor:

Pode ter vários bancos
Centraliza segurança
Controla firewall

No portal do Azure:

Azure SQL → Create
Você define:
- Server name → meu-servidor.database.windows.net
- Admin login
- Senha

2.2 Banco de dados

Dentro do servidor:

Você cria o banco nomeDoBanco
Define
- Camada (Basic / General Purpose / Business Critical)
- DTUs / vCores

2.3 Firewall do SQL Server

Por padrão ninguém consegue acessar o banco.

Você precisa configurar: Networking → Firewall rules

Opções:

✔️ Allow Azure services
✔️ Adicionar IP da sua máquina (para migrations locais)

⚠️ Sem isso:

App não conecta
Migration falha
Erro de timeout

👉 Em produção real:

Ideal é Private Endpoint
Mas para início: firewall simples resolve

3. Connection String, o elo entre a aplicação e o banco

Essa é uma das partes mais importante de todo deploy. Sem essa conexão, nada conecta com a base de dados.

Sem ela:

A aplicação sobe ✔️
O banco existe ✔️
Mas nada se comunica ❌

Ou seja: API no ar, mas toda requisição que depende de dados falha.

3.1 O que você já criou no Azure SQL Database

Ao criar sua base de dados no Azure (SQL Server), você definiu:

Nome do servidor
Nome da base de dados
Admin Login
Senha
Tipo de autenticação (SQL Authentication)

Essas informações são a base da sua connection string.

3.2 O que é, na prática, uma Connection String?

É um texto que informa à aplicação:

Onde está o banco
Qual banco acessar
Como autenticar
Como se comportar durante a conexão

Exemplo genérico:

Server=...
Database=...
User Id=...
Password=...

3.3 De onde vem o valor da Connection String?

No Azure SQL Database:

SQLDatabase
 → Settings
     → Connection strings

Normalmente você verá algo como:

Server=tcp:meuservidor.database.windows.net,1433;
Initial Catalog=MinhaBase;
PersistSecurityInfo=False;
User ID=adminuser;
Password=********;
MultipleActiveResultSets=False;
Encrypt=True;
TrustServerCertificate=False;
Connection Timeout=30;

Copie exatamente essa string e cole no campo Value.

3.4 Agora vamos ligar App → Banco

Essa configuração é feita diretamente no Azure App Service, sem precisar alterar código.

3.4.1 Caminho no Azure Portal

App Service
 → Settings
 → Configuration
 → Connection strings

Essa área funciona como um cofre de segredos da aplicação.

✅ Mais seguro

✅ Separado do código

✅ Ideal para ambientes (Dev / Homologação / Produção)

3.4.2 Nome da Connection String (Muito Importante)

Se você usa Entity Framework Core, o nome mais comum (e recomendado) é:

DefaultConnection

Esse nome precisa bater exatamente com o que está no seu Program.cs ou appsettings.json.

Exemplo comum no código:

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(
        builder.Configuration.GetConnectionString("DefaultConnection")));

Se o nome for diferente no Azure:

❌ A aplicação sobe

❌ Mas não encontra o banco

❌ Erro clássico: The ConnectionString property has not been initialized

4. Migrações

Agora vem a parte mais importante do deploy com banco. Vamos separar em três trilhas bem práticas:

Migration Manual Local → Azure SQL
Migration via GithubActions → Azure SQL (Pipeline)
Migration por script SQL (práticas usadas por empresas)

4.1. Migration Manual (local → Azure SQL)

Pré-requisitos:

Projeto com EF Core
Migrations já criadas

Isso não mexe no banco ainda, apenas gera os arquivos C#.

4.2. Liberar o acesso ao banco no Azure

Por padrão, o Azure SQL bloqueia tudo e precisamos autorizar nossa máquina local, sem isso nosso sistema dará o erro: Login failed / Timeout expired

O que isso faz:

Autoriza sua máquina local
Permite que o dotnet ef conecte no banco remoto

No Portal Azure:

Azure SQL Server
Networking
Firewall rules
Add your client IPv4 address
Save

4.3. Garantir que sua aplicação aponta para o Azure

Garante que seu arquivo appsettings.Development.json está apontando para o SQL Server no azure.

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=tcp:meuservidor.database.windows.net;..."
  }
}

4.4. Executar a migration

dotnet ef database update

O que acontece por trás:

EF abre conexão com o Azure SQL
Verifica se existe a tabela:

__EFMigrationsHistory

Se não existir → cria
Se existir → lê quais migrations já rodaram
Compara:
- Migrations no código
- Migrations no banco
Executa somente as pendentes
Registra a versão aplicada

Introdução ao Deploy

Yuri Peixinho — Thu, 08 Jan 2026 23:06:12 +0000

Introdução

Quando estamos desenvolvendo uma aplicação escrevemos o código em nosso computador. Esse código depois de escrito só consegue ser rodado em ambiente local e a aplicaçõo só pode ser acessada pelo seu próprio dispositivo.

Mas como faz pra esse código rodar 24h por dia e acessível para outras pessoas? O deploy é a resposta. É o processo de “pegar” um software e colocá-lo em um ambiente que execute ele continuamente de forma estável, segura e acessível.

O que precisa pra rodar o software?

Todo sistema em produção precisa de 4 coisas básicas.

Código (sua aplicação)
Máquina pra executar o código
Dados (banco de dados, arquivos)
Rede (internet)

Mais afinal, onde onde o deploy acontece?

O Deploy acontece no servidor. O servidor é um computador ligado 24h, com CPU, memória, disco, sistema operacional, internet, etc. Uma observação importante é que você pode usar seu computador como um servidor (mas não é recomendado)

Tipos de servidores (do mais simples ao moderno)

Servidor Físico

É uma máquina real em um datacenter, você cuida de tudo. Geralmente é caro e complexo

Máquina Virtual (VM)

Um servidor virtual dentro de outro servidor, você controla o SO (Sistema Operacional).

Azure VM
EC2 (AWS)

Plataforma Gerenciada (PaaS)

Você só cuida do código e a nuvem cuida do servidor

Azure App Service

Containers (Docker)

Seu aplicativo é empacotado com tudo que precisa e roda igual em qualquer lugar

Orquestração (Kubernates)

Gerencia vários containers, alta escala e complexidade

O que acontece durante um deploy?

Agora que sabemos o que é o deploy e quais são os tipos de servidores, vamos imaginar um deploy manual?

Desenvolvedor escreve o código
Compila o código (build)
Copia os arquivos para o servidor
Configura variáveis de ambiente (ex: string de conexão, senhas de integrações, etc.).
Inicia a aplicação
Abre porta de rede
Aponta um domínio
Monitora erros

Camadas de Validações de um Sistema backend

Yuri Peixinho — Mon, 10 Nov 2025 23:46:55 +0000

Introdução

Como você já deve saber, sistemas geralmente têm entrada e saída de dados (Input/Output). Esses dados de entradas são armazenados em alguma base de dados existente. Portanto, esses dados precisam ser controlados e validados para manter a consistência de sua aplicação.

Por exemplo, se temos um campo de CPF (11 dígitos fixos) não podemos deixar o usuário inserir em nossa base de dados um CPF que contém 8 ou 15 dígitos ou que ele consiga criar dois CPFs iguais.

Tipos de validações

No backend existem três níveis principais de validação e é importante entender a diferença entre os conceitos.

Validação de Entrada (Camada de API/Controller)
Validação de Negócio (Camada de Aplicação /Domain Service)\
Validação de Consistência/Infraestrutura

Validação de Entrada (Camadas de API/Controller)

Ocorre logo no início da aplicação (entrada de dados) e o objetivo é garantir que os dados cheguem válidos na camada de aplicação. É nessa camada que será realizado a validação posterior, de negócios. É aqui que o sistema valida a estrutura e o formato, mas nunca a lógica do negócio.

Exemplo: verificar se o CPF tem 11 dígitos, mas não se ele existe no banco.

Validação de Negócio (Camada da Aplicação/Domain Service)

Essa camada é posterior a validação de entrada. Caso todas as informações fornecidas no input da aplicação esteja correta, passamos para a fase da validação de negócio, seu objetivo é garantir que a ação faça sentido pra o sistema.

Existem dois níveis de validação de regra de negócio.

Regras de Entidades (invariantes)
Regras de negócio entre entidades (Serviço de Domínio)

Regras de Entidades (invariantes)

São regras auto-suficientes que pertencem a uma única entidade e vão dentro da própria classe. As invariantes servem pra garantir consistência do domínio.

Exemplos:

Não permitir criar um boleto para um cliente bloqueado.
Impedir alteração de uma remessa já enviada.
Garantir unicidade de um registro lógico (ex: CPF de uma pessoa).

public class Remessa
{
    public Guid RemessaId { get; private set; }
    public int BancoId { get; private set; }
    public Header Header { get; private set; }
    public string ArquivoTXT { get; private set; }

    public Remessa(int bancoId, Header header, string arquivoTXT)
    {
        BancoId = bancoId;
        Header = header;
        ArquivoTXT = arquivoTXT;

        ValidarDominio();
    }

    public void ValidarDominio()
    {
        if (Header is null)
            throw new DomainException("Header da remessa não pode ser nulo.");

        if (string.IsNullOrWhiteSpace(ArquivoTXT))
            throw new DomainException("Arquivo TXT não pode estar vazio.");

        if (Header.Agencia.Length != 4)
            throw new DomainException("A agência deve ter 4 dígitos.");
    }
}

Repare que:

ValidarDominio() garante que nenhum objeto Remessa inválido possa existir.
O construtor força a validação logo na criação.
As propriedades têm private set, ou seja, ninguém de fora pode alterar o estado diretamente.

E você pode criar uma DomainException personalizada (mais elegante do que ValidationException):

public class DomainException : Exception
{
    public DomainException(string message) : base(message) { }
}

Regras de negócios entre Entidades

Essa camada geralmente valida as relações entre entidades, processos e cenário do negócio. Ele é o ponto que entende o contexto e orquestra o uso correto das entidades.

Essa validação não valida formatos ou invariantes. Ele valida cenários de negócios como:

“Um cliente não pode ter duas assinaturas ativas”
“Não é possível emitir uma fatura para um pedido cancelado”
“O banco informado precisa existir e estar ativo”

Percebe que são regras contextuais e relacionais e não estruturais?

Em qua fluxo de processo ela se encaixa? Ela vive entre o application Service e o Domain, e geralmente é acionada logo depois que os dados foram validados e antes de criar ou persistir entidades.

Controller  
  ⇣  
DTO Validation (FluentValidation) (Validação de formato)
  ⇣  
Application Service  
  ⇣  
Business Validation (processo / contexto) <- É aqui que entra!
  ⇣  
Domain Validation (invariantes da entidade)  
  ⇣  
Repository / Persistência

Normalmente essa etapa de validação se localiza den tro de Application:

Application/
│
├── Validation/
│   ├── DTO/                # FluentValidation
│   ├── Business/           # Regras contextuais
│   └── Domain/             # (opcional: regras complexas do domínio)

Essa camada de validação geralmente utiliza repositórios, serviços de domínios e contexto de processos. Isto é:

Repositório: verificar estados do sistema (se já exist algo no banco)
Serviços de Domínio: se a regra envolve lógica consolidada, por exemplo: verificar limite de crédito, calcular juros, validar estoque
Contexto de Processo: estado do sistema e coerência entre entidades, exemplo: impedir fatura de pedido cancelado, proibir duplicidade de remessa.

Validação de Consistência/Infraestrutura

Essa é a última etapa de validação e a mais crucial. O objetivo é proteger o sistema e o banco de dados de inconsistências estruturais. Ocorre na camada de repository e banco de dados.

Exemplos:

Chaves únicas (UNIQUE, PRIMARY KEY).
Relacionamentos (FOREIGN KEY).
Restrições de tipo (CHECK, NOT NULL).

Abordagem Vertical Slice (VSA) em MediatR

Yuri Peixinho — Wed, 29 Oct 2025 02:13:53 +0000

Introdução

Existem algumas formas de estruturar o MediatR. Geralmente a estrutura utilziada é chamada de Estrutura Horizontal e é bem utiliza em projetos de pequeno porte. Acontece que abordagem horizontal ficaria insustentável rapidamente, pois a pasta Commands e Queries ficaria com centenas de arquivos.

Estrutura Horizontal

Projeto.Application
│
├── Commands
│   ├── Remessa
│   │   ├── CreateRemessaCommand.cs
│   │   └── CreateRemessaCommandHandler.cs
│   ├── Usuario <--- Crescendo
│   │   ├── CreateUserCommand.cs
│   │   └── ChangePasswordCommand.cs
│
├── Queries
│   ├── Remessa
│   │   └── GetRemessaByIdQuery.cs
│   ├── Usuario <--- Crescendo
│   │   └── GetUserByEmailQuery.cs
..

A Melhor Abordagem: Vertical Slice Architecture (VSA)

O VSA com CQRS/MediatR prioriza a organização do código pro funcionalidade (feature/casos de usos) em vez de por tipo de objeto.

Então, em vez de ter comandos de várias entidades misturados na mesma pasta, você agrupa tudo que se refere aquela funcionalidade específica no mesmo lugar.

O trabalho do VSA é inverter isso, criando pastas para cada feature principal do sistema, e dentro dela, agrupa os Commands, Queries e DTOS relacionados.

Projeto.Application
│
├── Features  // Ou 'UseCases', 'Slices', etc.
│   
│   ├── Remessas  // Feature: Gerenciamento de Arquivos de Remessa
│   │   ├── CreateRemessa
│   │   │   ├── CreateRemessaCommand.cs
│   │   │   └── CreateRemessaCommandHandler.cs
│   │   ├── GetRemessaById
│   │   │   ├── GetRemessaByIdQuery.cs
│   │   │   └── GetRemessaByIdQueryHandler.cs
│   │   └── RemessaDTO.cs // DTOs que são específicos da feature Remessa
│   
│   ├── Usuarios // Feature: Gerenciamento de Usuários e Contas
│   │   ├── CreateUser
│   │   │   ├── CreateUserCommand.cs
│   │   │   └── CreateUserCommandHandler.cs
│   │   ├── GetUserDetails
│   │   │   ├── GetUserDetailsQuery.cs
│   │   │   └── GetUserDetailsQueryHandler.cs
│   │   └── UserDTO.cs 
│   
│   └── Contas // Feature: Gerenciamento de Contas Bancárias
│       ├── CreateContaBancaria
│       │   ├── CreateContaBancariaCommand.cs
│       │   └── CreateContaBancariaCommandHandler.cs
..

Desse modo, a gente consegue concluir que existe algumas vantagens:

Alta coesão e baixo acoplamento
Escalabilidade e Onborading (fácil para o desenvolvedor entender o sistema)
Isolamento de Dependências (DI)
Otimização do MediatR

Dica extra: Handle na mesma pasta de Command

Muitas vezes, o Command e o Handler são colocados no mesmo arquivo, reduzindo a poluição de arquivos, mas mantendo a estrutura de pastas clara. Exemplo:

// Projeto.Application/Features/Remessas/CreateRemessa/CreateRemessa.cs

public class CreateRemessaCommand : IRequest<RemessaDTO>
{
    // Propriedades do Command
}

public class CreateRemessaCommandHandler : IRequestHandler<CreateRemessaCommand, RemessaDTO>
{
    private readonly IRemessaRepository _remessaRepository;
    // ...
    public async Task<RemessaDTO> Handle(CreateRemessaCommand request, CancellationToken cancellationToken)
    {
        // Lógica de domínio/infraestrutura
    }

Descomplicando Simple Factory Method

Yuri Peixinho — Wed, 29 Oct 2025 01:30:52 +0000

Introdução

O Simple Factory Method não é um padrão de projeto oficial GOF, isso significa que ele não está catalogados nos livros, portanto é reconhecido como uma introdução a outros dois design patterns: Factory Method e Abstract Factory.

Sua função é centralizar a responsabilidade de criar e entregar objetos de acordo com os parâmetros de entrada. Ele ajuda a reduzir o acoplamento e organizar a lógica de criação, por isso é considerado um design pattern criacional.

Quando surge a necessidade?

Como já dito, podemos utilizar quando queremos centralizar a criação de objetos, com o objetivo do cliente não precisar reconhecer as classes concretas, o que gera desacoplamento.

Então, alguns contextos são:

Vários tipos de objetos que compartillham a mesma interface
Reduzir o acoplamento de criação
Facilita manutenção, extensão e escalabilidade do projeto. Se você tem um novo tipo de objeto basta adicionar no Factory sem tocar no cliente.

Exemplo prático

Temos um sistema de geração de boletos que implementam para diferentes bancos:

BancoDoBrasil
BancoBradesco

Queremos que o cliente da API peça um boleto sem se preocupar com qual classe concreta será instanciada.

Interface do Boleto

public interface IBoleto 
{
        string Gerar();
}

Boletos Concretos

public class BoletoBancoDoBrasil : IBoleto
{
    public string Gerar() => "Boleto gerado pelo Banco A";
}

public class BoletoBradesco : IBoleto
{
    public string Gerar() => "Boleto gerado pelo Banco B";
}

Controller SEM Factory

Nesse exemplo temos os seguintes problemas:

Controller acoplado às classes concretas (BancoDoBrasil, BancoBradesco)
Adicionar um novo banco mexe diretamente no Controller
Código depende diretamente da implementação completa

using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/[controller]")]
public class BoletosController : ControllerBase
{
    [HttpGet("{banco}")]
    public IActionResult GerarBoleto(string banco)
    {
        IBoleto boleto;

        switch (banco.ToLower())
        {
            case "BancoDoBrasil":
                boleto = new BoletoBancoDoBrasil();
                break;
            case "BancoBradesco":
                boleto = new BoletoBradesco();
                break;
            default:
                return BadRequest(new { Erro = "Banco não suportado" });
        }

        var resultado = boleto.Gerar();
        return Ok(new { Mensagem = resultado });
    }
}

Controller COM Factory

Aqui, o controller usa a fábrica (Factory), não se importando com as classes concretas:

Controller não conhece classes concretas.
Fácil de adicionar novos tipos de boletos: só precisa atualizar a factory, o controller continua intacto.
Código mais limpo e desacoplado, seguindo o princípio Open/Closed (aberto para extensão, fechado para modificação).

Criando o método estático Factory

public static class BoletoFactory
{
    public static IBoleto Criar(string banco)
    {
        return banco.ToLower() switch
        {
            "BancoDoBrasil" => new BoletoBancoDoBrasil(),
            "BancoBradesco" => new BoletoBradesco(),
            _ => throw new ArgumentException("Banco não suportado")
        };
    }
}

using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/[controller]")]
public class BoletosController : ControllerBase
{
    [HttpGet("{banco}")]
    public IActionResult GerarBoleto(string banco)
    {
        try
        {
            var boleto = BoletoFactory.Criar(banco); // Factory faz o trabalho
            var resultado = boleto.Gerar();
            return Ok(new { Mensagem = resultado });
        }
        catch (ArgumentException ex)
        {
            return BadRequest(new { Erro = ex.Message });
        }
    }
}

Evolução

Quando o projeto cresce, geralmente o Simple Factory evolui para o Factory Method, onde cada tipo concreto pode ter sua própria classe factory.

MediatR (bônus CQRS + Clean Architecture)

Yuri Peixinho — Tue, 28 Oct 2025 00:04:34 +0000

Introdução

O MediatR é uma biblioteca .NET que facilita a implementação prática do design pattern comportamental Mediator. O mediator centraliza a comunicação entre os componentes do sistema usando mensagens (Requests) e handlers (Handlers).

Existem dois tipos principais de mensagens:

Tipo	Uso	Retorno
Command	Executa uma ação (criar, atualizar, deletar)	Pode retornar `Unit` (void) ou algum resultado
Query	Busca dados	Retorna um valor, DTO ou objeto

Estrutura básica:

IRequest<TResponse>: representa a requisição (Command ou Query)

IRequestHandler<TRequest, TResponse>: lida com a requisição

IMediator: interface usada para enviar as requisições

Commands, Handlers e Queries

Antes de aprofundarmos tecnicamente e de forma prática em MediatR é importante entender sobre os Commands e Queries. Esses dois termo são conceitos que estão diretamente ligados ao CQRS (Command Query Responsability Segregation).

No MediatR, você envia um Command ou Query, e o Handler é responsável por processar e orquestrar toda a lógica relacionada a essa requisição. Dessa forma, Controllers ou Services não precisam conhecer os detalhes internos de implementação do Command ou Query, mantendo o código mais desacoplado e organizado.

Commands

Definem a ação que muda o estado do objeto (entidade no banco)
Devem implementar IRequest<T>, onde T é o tipo de retorno (pode ser Unit se não retornar nada)

public record CreateUserCommand(string Name, string Email) : IRequest<int>;

Aqui int é o ID do usuário criado.

Queries

Definem a ação de leitura de um objeto (entidade no banco), sem alteração de dados
Também implementam umIRequest<T>

public record GetUserByIdQuery(int Id) : IRequest<UserDto>;

Retorna UserDto, ou seja, os dados do usuário.

Handlers

É aqui que a mágica acontece, cada Command/Query tem um handler separado, implementando IRequestHandler<TRequest, TResponse>

Exemplo de Command Handler

public class CreateUserCommandHandler : IRequestHandler<CreateUserCommand, int>
{
    private readonly IUserRepository _repo;
    public CreateUserCommandHandler(IUserRepository repo) => _repo = repo;

    public async Task<int> Handle(CreateUserCommand request, CancellationToken ct)
    {
        var user = new User { Name = request.Name, Email = request.Email };
        await _repo.AddAsync(user);
        return user.Id;
    }
}

Exemplo de Query Handler

public class GetUserByIdQueryHandler : IRequestHandler<GetUserByIdQuery, UserDto>
{
    private readonly IUserRepository _repo;
    public GetUserByIdQueryHandler(IUserRepository repo) => _repo = repo;

    public async Task<UserDto> Handle(GetUserByIdQuery request, CancellationToken ct)
    {
        var user = await _repo.GetByIdAsync(request.Id);
        return new UserDto(user.Id, user.Name, user.Email);
    }
}

Exemplo prático

Instalação

Install-Package MediatR
Install-Package MediatR.Extensions.Microsoft.DependencyInjection

Exemplo prático – CRUD de Produto

Vamos comparar o projeto de API em Clean Architecture com camadas. Teremos dois cenários, o primeiro sem a utilização do MediatR, e o segundo cenário com ele aplicado.

Application
 ├── Commands
 │    ├── CreateProductCommand.cs
 │    └── UpdateProductCommand.cs
 ├── Queries
 │    ├── GetProductByIdQuery.cs
 │    └── GetAllProductsQuery.cs
 ├── Handlers
 │    ├── CreateProductHandler.cs
 │    ├── GetProductByIdHandler.cs
Infrastructure
 └── Repositories
Presentation (API)
 └── Controllers

Sem MediatR (código acoplado)

Aqui o Controller conhece diretamente o serviço/repositório e faz toda a lógica:

// Controller
[ApiController]
[Route("api/users")]
public class UsersController : ControllerBase
{
    private readonly IUserRepository _userRepository;

    public UsersController(IUserRepository userRepository)
    {
        _userRepository = userRepository;
    }

    [HttpPost]
    public async Task<IActionResult> Create(UserCreateDto dto)
    {
        // Lógica de negócio diretamente no controller
        if (string.IsNullOrEmpty(dto.Name) || string.IsNullOrEmpty(dto.Email))
            return BadRequest("Nome e email são obrigatórios.");

        var user = new User { Name = dto.Name, Email = dto.Email };
        await _userRepository.AddAsync(user);

        return Ok(user.Id);
    }
}

O problema aqui é:

Controller faz validação e persistência, acumulando responsabilidades.
Difícil testar a lógica isoladamente.
Difícil reaproveitar a lógica em outro ponto da aplicação.

Com MediatR (código desacoplado)

Nesse cenário separamos Command, Handler e Controller.

// Command
public record CreateUserCommand(string Name, string Email) : IRequest<int>;

// Handler
public class CreateUserCommandHandler : IRequestHandler<CreateUserCommand, int>
{
    private readonly IUserRepository _userRepository;

    public CreateUserCommandHandler(IUserRepository userRepository)
    {
        _userRepository = userRepository;
    }

    public async Task<int> Handle(CreateUserCommand request, CancellationToken cancellationToken)
    {
        if (string.IsNullOrEmpty(request.Name) || string.IsNullOrEmpty(request.Email))
            throw new ArgumentException("Nome e email são obrigatórios.");

        var user = new User { Name = request.Name, Email = request.Email };
        await _userRepository.AddAsync(user);
        return user.Id;
    }
}

// Controller
[ApiController]
[Route("api/users")]
public class UsersController : ControllerBase
{
    private readonly IMediator _mediator;

    public UsersController(IMediator mediator)
    {
        _mediator = mediator;
    }

    [HttpPost]
    public async Task<IActionResult> Create([FromBody] CreateUserCommand command)
    {
        var id = await _mediator.Send(command); // envia o comando para o Handler
        return Ok(id);
    }
}

Controller não conhece a lógica interna, só envia o comando.
Lógica isolada no Handler, fácil de testar unitariamente.
Fácil adicionar validações, logs, notificações, etc., sem mudar o Controller.
Código mais organizado e escalável em projetos grandes.

Mediator aplicado ao Clean Arch + CQRS

Ao aplicar o padrão MediatR + CQRS + Clean Arch em um cenário simples como apenas a listagem de alguns produtos (uma única ação) pode deixar a visão dos desenvolvedores nebulosa.

Em sistemas complexos, essa separação evita acoplamento rígido, quando uma mudança na infraestrutura é dada, como trocar o banco de dados, que bra a lógica de negócio.

O objetivo aqui é entender o propósito de “tanta separação de camadas e responsabilidades” e deixar claro como o Handle isola a complexidade do serviço.

O Fluxo Complexo com CQRS/Mediator:

Vamos imaginar o sistema de gerenciamentos de pedidos e estoques (e-commerce)

1. Controller e Command

O Controller recebe a requisição de finalização e despacha um Command.

// OrdersController (Complexo)
public async Task<IActionResult> PlaceOrder([FromBody] PlaceOrderDTO orderDto)
{
    // 1. Mapeia DTO para Command
    var command = _mapper.Map<PlaceOrderCommand>(orderDto);

    // 2. Despacha o Command via Mediator
    var orderId = await _mediator.Send(command); 

    return Ok(new { orderId });

2. Service/Mediator e CommandHandler (Onde a Complexidade é Isolada)

O PlaceOrderCommand é enviado para o PlaceOrderCommandHandler. É aqui que o Mediator/CQRS justifica sua existência.

// Em CleanArchMvc.Application.Products.Handlers;
// Dependências injetadas que representam o acesso à infraestrutura e a outros serviços
// As interfaces (IOrderRepository, IInventoryService, IPaymentGateway, etc.)
// estão definidas na Camada de Domínio e implementadas na Camada de Infraestrutura.
public class PlaceOrderCommandHandler : IRequestHandler<PlaceOrderCommand, int>
{
    private readonly IOrderRepository _orderRepository;
    private readonly IInventoryService _inventoryService; // Ex: Serviço para chamar API de Estoque
    private readonly IPaymentGateway _paymentGateway; // Ex: Serviço para chamar API de Pagamento (Stripe/PagSeguro)

    public PlaceOrderCommandHandler(
        IOrderRepository orderRepository,
        IInventoryService inventoryService,
        IPaymentGateway paymentGateway)
    {
        _orderRepository = orderRepository;
        _inventoryService = inventoryService;
        _paymentGateway = paymentGateway;
    }

    public async Task<int> Handle(PlaceOrderCommand request, CancellationToken cancellationToken)
    {
        // 1. Lógica de Domínio: Criação da Entidade
        // Assumimos que a Entidade 'Order' tem um método estático de criação que 
        // aplica as regras de negócio de criação (ex: define o status inicial).
        var order = Order.CreateNew(
            request.CustomerEmail, 
            request.ShippingAddress, 
            request.TotalAmount, 
            request.Items.Select(i => new OrderItem(i.ProductId, i.Quantity)).ToList()
        );

        // 2. Orquestração: Verificação de Estoque (Chama um serviço de infraestrutura)
        // Isso pode ser uma chamada a uma API externa de gerenciamento de estoque.
        var stockCheck = await _inventoryService.CheckStockAvailability(order.Items);

        if (!stockCheck.IsAvailable)
        {
            // Lança uma exceção de domínio (que será tratada globalmente na WebUI)
            throw new DomainException($"Estoque indisponível para o(s) produto(s): {stockCheck.UnavailableProducts}.");
        }

        // 3. Persistência (Ponto 1): Salva o Pedido Inicial (Status: Pendente/Aguardando Pagamento)
        // Isso garante que o pedido existe no banco antes de tentar o pagamento,
        // permitindo o rastreio de pagamentos falhos.
        await _orderRepository.AddAsync(order);

        // 4. Orquestração: Processamento de Pagamento (Chama outro serviço de infraestrutura)
        var paymentResult = await _paymentGateway.ProcessPayment(
            order.Id, 
            request.TotalAmount, 
            request.PaymentInfo // Assumindo que o Command tem dados de cartão/boleto
        );

        if (!paymentResult.Success)
        {
            // 5. Lógica de Compensação (Rollback Lógico)
            // Se o pagamento falhar, atualiza o status do pedido e lança uma exceção.
            order.CancelOrder(); // Método na Entidade Order
            await _orderRepository.UpdateAsync(order);

            throw new PaymentFailedException(paymentResult.ErrorMessage);
        }

        // 6. Lógica de Domínio: Pedido Aprovado
        order.ApproveOrder(paymentResult.TransactionId); // Método na Entidade Order (muda o status)

        // 7. Persistência (Ponto 2): Salva as Mudanças da Aprovação
        await _orderRepository.UpdateAsync(order);

        return order.Id;
    }
}

Como dá pra perceber acima, o código é a materialização da SoC, separação de preocupações (Separation of Concerns) e do SRP, Princípio da Responsabilidade única (SRP).

A função principal do handle acima não é executar nenhuma tarefa bruta (como acessar o banco de dados), mas sim ORQUESTRAR a sequência dos passos que definem o processo de “Fazer um pedido”. (a lógica de negócio complexa)

.NET AutoMapper (DTOs)

Yuri Peixinho — Sat, 25 Oct 2025 16:24:35 +0000

Introdução

O AutoMapper é uma biblioteca utilizada para mapear objetos. Ele ajuda a resolver esse problema ao automatizar o mapeamento entre diferentes objetos de diferentes camadas, como entre entidades de bancos de dados e objetos de transferências de dados (DTOs). Isso facilita o desenvolvimento ao reduzir a quantidade de código manual para conversões, promovendo um maior desacoplamento e flexibiliade do projeto.

O problema que o AutoMapper resolve

Imagine que você tem uma aplicação que têm muitas entidades e DTOs parecidos, como por exemplo Product. Você precisará mapear manualmente dezenas ou centenas de classes e DTO, e fazer isso

Exemplo didático do problema

Vamos retomar o exemplo do Product, descrito acima.

Imagine que você tem um Model de Product:

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}

E um DTO que representa o que você quer enviar ao cliente sem o ID:

public class ProductDTO
{
    public string Name { get; set; }
    public decimal Price { get; set; }
}

O problema é: toda vez que você quiser converter de Product -> ProductDTO, você teria que escrever:

var productDTO = new ProductDTO
{
    Name = product.Name,
    Price = product.Price
};

e quando for o contrário (DTO → Entidade)

var product = new Product
{
    Name = productDTO.Name,
    Price = productDTO.Price
};

Essa prática em projetos de pequeno porte pode ser eficiente, mas em projetos grandes significa:

Muito código repetitivo
Alta chance de erro (esquecer um campo, errar um nome, etc.).
Difícil manutenção (se mudar o nome de uma propriedade, você precisará alterar em todos os lugares)

Exemplo didático da solução (AutoMapper)

O papel do automapper é automatizar essa conversão. Ele faz um mapeamento de propriedades entre objetos de tipos diferentes, desde que o nomes e tipos sejam compatíveis.

Primeiro você cria uma configuração de mapeamento (Profile)

using AutoMapper;

public class MappingProfile : Profile
{
    public MappingProfile()
    {
        CreateMap<Product, ProductDTO>(); // diz como mapear de Product → ProductDTO
    }
}

Depois registra essa configuração no seu projeto (normalmente no Program.cs ou em arquivo de configurações como método de extensão)

using AutoMapper;

public class MappingProfile : Profile
{
    public MappingProfile()
    {
        CreateMap<Product, ProductDTO>(); // diz como mapear de Product → ProductDTO
    }
}

E finalmente, em qualquer lugar do código, você pode converter objetos facilmente:

var productDTO = _mapper.Map<ProductDTO>(product);

Desse modo o AutoMapper automatica copia as propriedades Name, Price sem você precisar escrever nada disso manualmente.

Registrar serviços do AutoMapper

O registro do automapper pode ser feito de diferentes maneiras, e dependem da estrutura e do tamanho do projeto.

Ele deve ser feito uma única vez no ponto central da aplicação, onde o container de injeção de dependência deve ser configurado

Dependendo da arquitetura, isso pode ficar em lugares diferentes:

Program.cs (projetos .NET 6+)
Startup.cs (projetos .NET 5 ou anteriores)
um método de extensão (boa prática para Clean Architecture)

Projeto simples sem camadas

Nos projetos mais simples, geralmente configuramos no Program.cs do projeto:

using AutoMapper;
using MyApp.Mappings; // pasta onde ficam seus Profiles

var builder = WebApplication.CreateBuilder(args);

// Registro do AutoMapper
builder.Services.AddAutoMapper(typeof(MappingProfile));

var app = builder.Build();

app.Run();

Projeto com Clean Architecture

Esse é o cenário mais comuns em projetos profisisonais. A ideia é criar um método de extensão para centralizar os registros dessa camada:

using Microsoft.Extensions.DependencyInjection;
using System.Reflection;

namespace MyApp.Application
{
    public static class DependencyInjection
    {
        public static IServiceCollection AddApplication(this IServiceCollection services)
        {
            services.AddAutoMapper(Assembly.GetExecutingAssembly());
            return services;
        }
    }
}

Quando usar vs. Quando não usar

É importante entender o contexto de arquitetura e escalabilidade do projeto antes de decidir utilizar o AutoMapper.

Situação	Recomendação
Muitos DTOs parecidos e simples	✅ AutoMapper é ótimo
Projeto pequeno / poucos mapeamentos	❌ Faça manualmente
Precisa de controle fino / regras de negócio	❌ Manual
Busca performance máxima	⚠️ Prefira Mapster ou manual

Alternativas modernas ao AutoMapper

Mapster: mais rápido e com menos configuração.

Manual mapping + extensions: simples e explícito, ideal para APIs pequenas:

public static UserDto ToDto(this User user) =>
    new UserDto(user.Id, user.Name, user.Email);