DEV Community

Cover image for 🧭 Comunicação entre a Camada de Aplicação e o Domínio no .NET
Danilo O. Pinheiro, dopme.io
Danilo O. Pinheiro, dopme.io

Posted on

🧭 Comunicação entre a Camada de Aplicação e o Domínio no .NET

#csharp #aspdotnet #dotnet

A Clean Architecture e as abordagens em camadas no .NET propõem uma separação clara de responsabilidades. Um dos pontos fundamentais nesse modelo é como a Application Layer interage com a Domain Layer — ou seja, como os casos de uso (Application) acessam e manipulam regras de negócio (Domain), mantendo a arquitetura coesa, testável e desacoplada.

Neste artigo, vamos explorar:

  • 📐 O papel de cada camada (Application x Domain)
  • 🔄 Padrões comuns de comunicação (Interfaces, Handlers, Services)
  • 💡 Exemplos práticos com C#
  • ✅ Boas práticas e armadilhas comuns

🧱 Entendendo as Camadas

🔷 Application Layer

A Application Layer é responsável por orquestrar os fluxos do sistema. Ela executa os casos de uso, valida entradas e coordena ações de domínio.

📌 Contém:

  • Handlers (Commands/Queries)
  • DTOs
  • Validadores
  • Interfaces do domínio

🔶 Domain Layer

A Domain Layer é onde mora o “coração” da sua aplicação. Ela contém a lógica de negócio, entidades ricas, value objects, services de domínio e interfaces.

📌 Contém:

  • Entidades
  • Value Objects
  • Domain Services
  • Interfaces (como repositórios)

🔁 Fluxo da Comunicação 

┌────────────────────────┐
│    Application Layer   │
│  (Orquestra os casos)  │
└────────────────────────┘
            ↓
[Invocações indiretas por interfaces]
            ↓
┌────────────────────────┐
│     Domain Layer       │
│ (Regras de negócio)    │
└────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

A camada de Application nunca deve instanciar diretamente objetos da infraestrutura ou acessar persistência sem uma interface.

🛠️ Exemplo Prático com C# e Clean Architecture

1. Entidade de Domínio 

// Domain/Entities/Order.cs
public class Order
{
    public Guid Id { get; private set; }
    public string CustomerEmail { get; private set; }
    public List<string> Items { get; private set; }

    public Order(string customerEmail, List<string> items)
    {
        Id = Guid.NewGuid();
        CustomerEmail = customerEmail;
        Items = items;

        if (Items == null || !Items.Any())
            throw new ArgumentException("Order must contain at least one item.");
    }
}
Enter fullscreen mode Exit fullscreen mode

2. Interface de Repositório no Domínio 

// Domain/Interfaces/IOrderRepository.cs
public interface IOrderRepository
{
    Task SaveAsync(Order order);
}
Enter fullscreen mode Exit fullscreen mode

3. Handler na Application Layer 

// Application/Orders/Commands/CreateOrderCommand.cs
public record CreateOrderCommand(string CustomerEmail, List<string> Items) : IRequest<Guid>;
Enter fullscreen mode Exit fullscreen mode 
// Application/Orders/Handlers/CreateOrderHandler.cs
public class CreateOrderHandler : IRequestHandler<CreateOrderCommand, Guid>
{
    private readonly IOrderRepository _repository;

    public CreateOrderHandler(IOrderRepository repository)
    {
        _repository = repository;
    }

    public async Task<Guid> Handle(CreateOrderCommand request, CancellationToken cancellationToken)
    {
        var order = new Order(request.CustomerEmail, request.Items);

        // Aplica lógica de domínio via entidade
        await _repository.SaveAsync(order);

        return order.Id;
    }
}
Enter fullscreen mode Exit fullscreen mode

✅ Boas Práticas

  • Não coloque lógica de negócio na camada Application. Ela deve apenas orquestrar os passos.
  • A camada Application depende da Domain, mas nunca o contrário.
  • A Domain Layer deve ser totalmente isolada de ASP.NET Core, MediatR, EF Core ou qualquer tecnologia externa.
  • Use interfaces para comunicar com persistência (Repositórios) ou serviços externos.
  • Teste os Handlers e Serviços de Domínio isoladamente.

⚠️ Erros Comuns

❌ Colocar regras como validação de email, cálculo de valores, ou restrições de negócio nos Handlers da Application.
✅ Essas responsabilidades são do Domínio.

❌ Deixar o domínio dependente de EF Core ou ILogger.
✅ Use interfaces e injeção de dependência para manter o domínio limpo e testável.

🔧 Organização de Pastas 

src/
├── API/                  # Interface HTTP (Controllers, DTOs, Filters)
├── Application/          # Casos de uso, Handlers, DTOs
├── Domain/               # Entidades, Interfaces, Regras de Negócio
├── Infrastructure/       # EF Core, serviços externos, repositórios
└── Shared/               # Utilitários e configurações comuns
Enter fullscreen mode Exit fullscreen mode

✅ Conclusão

A comunicação entre Application e Domain é o elo mais importante da arquitetura. Quando feita da forma correta:

  • Sua aplicação se torna modular e testável
  • É possível trocar infraestrutura sem afetar regras de negócio
  • O domínio se torna o verdadeiro “coração” do seu sistema

🤝 Conecte-se Comigo

Se você trabalha com .NET moderno e quer dominar arquitetura, C#, DevOps ou interoperabilidade, vamos conversar:

Top comments (0)