Aula 10: Programação por Domínios (DDD)

1. Além do CRUD: Por que DDD?

A maioria das aplicações de software falha não por falta de tecnologia, mas por falha na compreensão do negócio. Muitas vezes, desenvolvedores focam em tabelas de banco de dados e telas de interface antes de entenderem as regras que governam o problema.

O DDD não é sobre "onde colocar os arquivos", mas sobre como modelar o software para que ele reflita a realidade do negócio. Em projetos de Sistemas de Informação, onde lidamos com KPIs, Dashboards e processos gerenciais, a clareza do domínio é a diferença entre um sistema útil e um "legado instantâneo".

2. Design Estratégico: O "Big Picture"

Antes de escrever classes, precisamos definir as fronteiras do nosso sistema.

Linguagem Ubíqua (Ubiquitous Language)

É um vocabulário comum compartilhado por Especialistas de Negócio e Desenvolvedores. Se o gestor chama um processo de "Ciclo de Apuração", esse nome DEVE estar no código. Evite nomes técnicos como DataProcessManager.

Bounded Context (Contexto Delimitado)

Um sistema grande não possui um único modelo. O termo "Usuário" significa algo diferente para o RH (Colaborador) e para o Financeiro (Pagador). Um Bounded Context define a fronteira onde um termo tem um significado específico e consistente.

3. Design Tático: Os Blocos de Construção

Como implementamos o domínio no código .NET?

Exemplo de Implementação (C#)

// Value Object (Imutável)
public record Dinheiro(decimal Valor, string Moeda);

// Entidade
public class Funcionario {
    public Guid Id { get; private set; } // Identidade
    public string Nome { get; private set; }
    public Dinheiro Salario { get; private set; } // Composição com VO

    public Funcionario(string nome, Dinheiro salario) {
        if (string.IsNullOrWhiteSpace(nome)) throw new DomainException("Nome inválido");
        Id = Guid.NewGuid();
        Nome = nome;
        Salario = salario;
    }

    public void Promover(Dinheiro novoSalario) {
        if (novoSalario.Valor <= Salario.Valor) 
            throw new DomainException("Novo salário deve ser maior");
        Salario = novoSalario;
    }
}

4. Agregados e Raízes de Agregação

Um Agregado é um cluster de objetos associados que tratamos como uma unidade para fins de mudança de dados. Cada agregado tem uma Raiz (Aggregate Root).

Por que isso importa no Projeto 9? Se você está gerando um Dashboard, ele pode ser um agregado que contém Widgets. Para garantir que o Dashboard não ultrapasse o limite de 10 widgets, essa regra deve estar na Raiz do Agregado (Dashboard).

5. Modelo de Domínio Rico vs. Anêmico

6. Organização em Camadas (Onion/Clean Architecture)

Para proteger o domínio, organizamos o projeto .NET em camadas concêntricas:

1. Domain (Núcleo)
   - Entidades, Value Objects, Interfaces de Repositório, Domain Services.
   - Dependência: NENHUMA.

2. Application (Orquestração)
   - Use Cases (Casos de Uso), DTOs, Mappers.
   - Dependência: Domain.

3. Infrastructure (Detalhes)
   - Implementação de Repositórios (Entity Framework), Envio de E-mail, APIs externas.
   - Dependência: Application, Domain.

4. WebAPI / Presentation (Entrada)
   - Controllers, Middlewares, Swagger.
   - Dependência: Infrastructure (via DI), Application.

7. Repositórios e Camada de Anticorrupção

Repositórios

Um repositório não é um DAO (Data Access Object). Enquanto o DAO foca em tabelas, o Repositório foca na Coleção de Agregados. Ele é uma interface definida no Domínio e implementada na Infraestrutura.

ACL (Anti-Corruption Layer)

Se o seu sistema precisa ler dados de um sistema legado "bagunçado", você cria uma ACL. Ela traduz os dados horríveis do legado para os seus Value Objects e Entidades limpos, impedindo que a "sujeira" externa contamine seu domínio.