Aula 10 • Projeto 9 • Sistemas de Informação

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.

Domínio Bounded Context Agregados Arquitetura .NET
Prof. Afonso Brandão • 2 horas • Semana 06

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 Domain no 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

  • DataService
  • GenericManager
  • UpdateStatus() sem explicar qual status de qual processo

Exemplo melhor

MetaMensal, IndicadorDeTurnover, FecharCicloDeAvaliacao(), ExportarRelatorioGerencial().

Pesquisar Ubiquitous Language

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.

Contexto Comercial
Produto = oferta vendável
→
Contexto Financeiro
Produto = item de faturamento
→
Contexto Analytics
Produto = dimensão para análise

Bounded Context é a fronteira dentro da qual um termo tem significado consistente.

Pesquisar Bounded Context

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.

Domínio RH
avaliação, turnover, ciclo, colaborador
Domínio Gestão
meta, decisão, visão executiva, consolidação
Domínio Analytics
métrica, projeção, histórico, comparação
Interseção útil
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.: Funcionario continua 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.

Projeto9.WebApi -> Controllers / Endpoints -> DTOs / Policies / Authentication Projeto9.Application -> Use cases / orchestrators / commands / queries Projeto9.Domain -> Entities / ValueObjects / DomainServices / Aggregates / Interfaces Projeto9.Infrastructure -> Repositories / EF or Dapper / external integrations / cache / files

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.

Pesquisar modelo de domínio em .NET

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.

Sistema Legado
→
ACL / Translator
→
Seu Domínio

Modelar capacidades, não telas

Telas mudam rápido. Capacidades de negócio tendem a durar mais.

Modelagem pobre

  • TelaDashboardService
  • PageFilterManager
  • Entidades espelhando JSON da UI

Modelagem melhor

  • ConsolidarIndicadoresMensais
  • FecharCicloDeAvaliacao
  • CompararMetaPlanejadaComRealizada

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?

Sobre este encontro

Programação por Domínios · Prof. Afonso

Objetivo de aprendizagem

Ao final do encontro, o estudante deve ser capaz de aplicar ao projeto os conceitos de Programação por Domínios. Escopo do encontro: Estruture seu código seguindo os princípios de Domain-Driven Design.

Estratégia do encontro

Exposição dialogada dos conceitos, alternada com aplicação guiada ao projeto do grupo, e fechamento com verificação do entendimento.

Estrutura do encontro

  1. 1. Além do CRUD: Por que DDD?
  2. 2. Design Estratégico: O "Big Picture"
  3. 3. Design Tático: Os Blocos de Construção
  4. 4. Agregados e Raízes de Agregação
  5. 5. Modelo de Domínio Rico vs. Anêmico
  6. 6. Organização em Camadas (Onion/Clean Architecture)
  7. 7. Repositórios e Camada de Anticorrupção
  8. 8. Desafio: Modelagem do Projeto 9
🏠 Home 📖 Material
1 / 3