Programação por Domínios
Como sair de código centrado em tela e tabela para uma arquitetura centrada em linguagem de negócio, contextos delimitados, comportamento e responsabilidade.
Storytelling: o sistema que sabia persistir, mas não sabia o negócio
Toda equipe já viu software que funciona no banco, mas falha no significado.
Cenário
O time constrói rápido: telas, CRUD, endpoints e tabelas. Tudo parece organizado. Só que cada área chama “cliente”, “meta”, “pedido” e “produto” por nomes parecidos com significados diferentes.
Sintoma
O mesmo termo aparece em vários lugares com regras conflitantes e o código passa a depender de exceções espalhadas.
Impacto
Relatórios divergem, integrações quebram, e qualquer mudança exige conhecer o sistema inteiro.
Virada
Programação por domínios organiza o software segundo o negócio real, não segundo a conveniência do framework.
O que é domínio
Domínio é o problema de negócio que o software precisa compreender e operar.
Domínio não é “banco de dados”, “API” ou “tela”. Domínio é o conjunto de conceitos, regras, exceções e decisões do negócio.
No projeto
- Indicadores gerenciais.
- Metas, desempenho, turnover, relatórios.
- Papéis diferentes olhando o mesmo fenômeno por óticas diferentes.
Erro comum
- Começar por tabela e endpoint.
- Modelar o sistema pela UI.
- Supor que um único modelo resolve todos os times.
DDD em uma frase
Domain-Driven Design é projetar software a partir do modelo de negócio e da linguagem que dá sentido a ele.
Não é
- Uma pasta chamada
Domainno projeto. - Um monte de interfaces sem regra de negócio.
- Uma moda para microservices apenas.
É
- Decidir fronteiras do negócio.
- Codificar regras com nomes que façam sentido para especialistas.
- Evitar que o modelo técnico destrua o modelo conceitual.
DDD vale especialmente quando o problema tem regra, exceção, ambiguidade e mudança frequente.
Linguagem ubíqua
Se o time e o negócio não usam a mesma linguagem, o código vira tradução defeituosa.
Ideia central
A linguagem ubíqua é o vocabulário compartilhado entre pessoas de produto, negócio e engenharia. Os nomes usados na conversa devem aparecer também no código, nos eventos, nos casos de uso e na documentação.
Exemplo ruim
DataServiceGenericManagerUpdateStatus()sem explicar qual status de qual processo
Exemplo melhor
MetaMensal, IndicadorDeTurnover, FecharCicloDeAvaliacao(), ExportarRelatorioGerencial().
Bounded Context: por que um modelo único falha
Quando a linguagem muda, o modelo também precisa mudar.
“Produto” pode significar catálogo comercial, item faturável ou linha analítica. Tentar unificar tudo à força gera ruído e acoplamento.
Produto = oferta vendável
Produto = item de faturamento
Produto = dimensão para análise
Bounded Context é a fronteira dentro da qual um termo tem significado consistente.
Monolito ruim x monolito modular
DDD não obriga microservices. Ele exige fronteiras claras.
| Modelo | Problema ou ganho | Leitura correta |
|---|---|---|
| Monolito acoplado | Uma mudança em RH quebra relatórios, billing e dashboard. | O problema não é ser monolito; é não haver limites de contexto. |
| Monolito modular | Módulos internos têm linguagem e dependências mais controladas. | Pode ser excelente para times pequenos e médios. |
| Microservices | Amplificam autonomia, mas também complexidade operacional. | Devem surgir quando o contexto e a equipe justificam a separação física. |
Diagrama visual: separação de responsabilidades por domínio
Os domínios se relacionam, mas não devem perder suas responsabilidades centrais.
avaliação, turnover, ciclo, colaborador
meta, decisão, visão executiva, consolidação
métrica, projeção, histórico, comparação
indicadores compartilhados
sem fundir contextos
Como ler o diagrama
- Os círculos mostram que os domínios colaboram, mas não são a mesma coisa.
- A área central representa dados e conceitos compartilhados, não um modelo único global.
- Cada domínio mantém sua linguagem, suas regras e sua responsabilidade principal.
Blocos básicos do domínio
O objetivo não é decorar nomes. É saber onde colocar responsabilidade.
Entidade
Tem identidade e ciclo de vida. Ex.: colaborador, meta, ciclo de avaliação.
Value Object
Vale pelos atributos, não por identidade. Ex.: período, faixa salarial, e-mail.
Serviço de Domínio
Comporta regra importante que não cabe naturalmente em uma única entidade.
Repositório
Abstrai acesso à persistência sem contaminar o núcleo com detalhes de banco.
Entidade x Value Object
Se tudo vira entidade, o modelo fica pesado. Se nada vira entidade, o modelo perde continuidade.
Entidade
- Possui identidade própria.
- Muda ao longo do tempo.
- Ex.:
Funcionariocontinua sendo o mesmo mesmo com nome ou salário atualizados.
Value Object
- É definido por seus valores.
- Tende a ser imutável.
- Ex.:
PeriodoCompetencia,EmailCorporativo,Moeda.
Agregado e Aggregate Root
Agregado é um limite de consistência. Nem tudo que se relaciona precisa ser salvo junto.
Ideia
- Um agregado reúne objetos que precisam manter invariantes juntos.
- O acesso externo acontece pela raiz do agregado.
- Transações fortes tendem a respeitar esse limite.
Exemplo
CicloDeAvaliacao pode ser a raiz que controla metas, avaliações e fechamento.
Um relatório consolidado pode ler esse conjunto, mas não faz parte do mesmo agregado operacional.
Regra prática: o que precisa mudar junto com consistência forte tende a viver no mesmo agregado.
Serviço de domínio x serviço de aplicação
Misturar coordenação técnica com regra de negócio é um dos erros mais comuns.
| Tipo | Responsabilidade | Exemplo |
|---|---|---|
| Serviço de Domínio | Expressa regra de negócio que depende de mais de uma entidade ou conceito. | CalcularIndicadorDeTurnover |
| Serviço de Aplicação | Orquestra caso de uso, transação, autorização e chamadas externas. | GerarRelatorioGerencialUseCase |
| Infraestrutura | Resolve persistência, mensageria, API externa, cache. | FuncionarioRepositorySql |
Arquitetura em camadas no .NET
O domínio deve conhecer o negócio. Não deve conhecer HTTP, EF, controller ou banco.
Regra de ouro
O projeto de domínio deve ser o lugar mais estável e semanticamente forte do sistema. Quanto mais regra vai para controller ou SQL solto, mais o domínio desaparece.
Anti-Corruption Layer (ACL)
Integrar não significa importar o modelo do outro sistema para dentro do seu núcleo.
Problema
Um sistema legado chama um indicador de score, outro chama de rating,
e o time começa a replicar nomes e regras incoerentes dentro do projeto.
Solução
A ACL traduz contratos externos para a linguagem do seu domínio, evitando contaminação conceitual.
Modelar capacidades, não telas
Telas mudam rápido. Capacidades de negócio tendem a durar mais.
Modelagem pobre
TelaDashboardServicePageFilterManager- Entidades espelhando JSON da UI
Modelagem melhor
ConsolidarIndicadoresMensaisFecharCicloDeAvaliacaoCompararMetaPlanejadaComRealizada
O front-end consome capacidades. Ele não deveria definir a ontologia do sistema.
Quando NoSQL orientado a agregados faz sentido
Nem toda modelagem precisa ser fortemente normalizada se a leitura de negócio pedir outro formato.
Faz sentido quando
- O acesso é centrado em um fluxo ou entidade raiz.
- Leituras compostas importam mais do que joins frequentes.
- Duplicação controlada compensa simplicidade operacional.
Cuidado
- Relatórios analíticos complexos podem ir para outra camada.
- Consistência eventual precisa ser entendida.
- Agregado não é desculpa para documento gigante sem critério.
Aplicando no Projeto 9
O objetivo é mapear contextos reais do dashboard e separar seus significados.
Contexto RH
- Turnover
- Avaliação
- Desempenho
Contexto Gestão
- Indicador executivo
- Metas consolidadas
- Comparativos
Contexto Analytics
- Preparação de dados
- Séries temporais
- Projeções
O mesmo dado pode aparecer em mais de um contexto, mas com responsabilidades e linguagem distintas.
Atividade de sala
Desenhar o domínio antes de codar mais uma tela.
Entrega do grupo
- Escolher um subdomínio principal da aplicação.
- Definir linguagem ubíqua mínima com 8 a 12 termos de negócio.
- Identificar pelo menos 2 bounded contexts.
- Listar entidades, value objects e um agregado raiz.
- Explicar o que fica em domínio, aplicação e infraestrutura.
Pergunta final
Se a mesma palavra aparece em três partes do sistema com significados diferentes, você está diante de um termo “genérico” ou de três contextos diferentes que ainda não foram explicitados?