Luis Soares
← Voltar aos artigos
Arquitetura10 jul 2026·12 min

Clean Architecture em .NET sem overengineering

Separar domínio de infraestrutura não significa criar dez camadas. Um guia pragmático para .NET 9.

LS
Luis Soares
Arquiteto de software — .NET · Azure · IA
[ imagem de capa · clean architecture ]

Clean Architecture virou sinônimo de pastas demais e abstrações que ninguém lê. O objetivo original é simples: proteger as regras de negócio dos detalhes que mudam — banco de dados, framework, protocolo. Tudo além disso é opcional.

O problema real

Quando a regra de negócio vive dentro do controller ou do DbContext, cada mudança de infraestrutura vira uma cirurgia de risco. O acoplamento não aparece no pull request — aparece seis meses depois, quando trocar de provedor custa uma sprint inteira.

csharp
// pure domain — zero framework references
public sealed class Order
{
    private readonly List<Line> _lines = [];
    public OrderId Id { get; }
    public Money Total => _lines.Sum(l => l.Price);

    public static Result<Order> Create(Cart cart) =>
        cart.IsEmpty
            ? Error.Validation("cart.empty")
            : new Order(cart.Lines);
}

As três camadas que importam

Na prática você precisa de três fronteiras claras — não dez. Domínio no centro, aplicação orquestrando os casos de uso, e infraestrutura na borda implementando as interfaces que a aplicação declara.

  • Domínio — entidades e regras de negócio. Zero dependências externas.
  • Aplicação — casos de uso que dependem de interfaces, nunca de implementações.
  • Infraestrutura — EF Core, HTTP, filas. Implementa o que a aplicação pede.

A regra de dependência é a única inegociável: o código de dentro nunca conhece o de fora.

csharp
public sealed class PlaceOrder(IOrderRepository repo, IClock clock)
{
    public async Task<Result<OrderId>> Handle(Cart cart, CancellationToken ct)
    {
        var order = Order.Create(cart);
        if (order.IsFailure) return order.Error;

        await repo.SaveAsync(order.Value, ct);
        return order.Value.Id;
    }
}

Quando não usar

Um CRUD interno, um script, um MVP de fim de semana — nada disso precisa de camadas. Elas custam navegação e cerimônia. Adote a separação quando as regras de negócio ficarem valiosas o suficiente para sobreviver ao framework que você usa hoje.

Comece com uma linha reta e curve quando a dor aparecer. Arquitetura é resposta a pressão, não decoração.

LS

Escrito por Luis Soares — arquiteto de software, rumo ao Microsoft MVP.