1. Delimitação de contextos: não subestime as fronteiras

Em equipes ágeis, a primeira armadilha é não delimitar claramente os contextos. Quando domínios de negócio diferentes convivem sem fronteiras explícitas, surgem dependências cruzadas, acoplamentos indesejados e políticas de integração inconsistentes. A consequência é um sistema mais difícil de evoluir, testar e escalar.

Como eu atuo para evitar isso:

• Defino bounds claros para cada contexto, mapeando o que é transacionalmente consistente dentro deles.
• Crio contratos explícitos de integração entre contextos, em vez de depender de dependências diretas entre domínios.
• Respeito invariantes dentro de cada contexto e permito consistência eventual entre contextos mediante eventos de domínio ou comandos com orquestração adequada.

2. Linguagem ubíqua: uma voz única para o domínio

Um erro comum é permitir que termos de negócio sejam usados de forma ambígua ou conflitante entre equipes. Nesse caso, código, testes e documentação vão contra a intenção do negócio, gerando ruído e retrabalho.

Minha prática é promover uma linguagem ubíqua consolidada e refletida no código:

• Adoto nomes de classes, métodos e eventos alinhados aos termos do negócio.
• Constrojo um glossário vivo e reviso nomenclaturas com a equipe de negócio periodicamente.
• Garanto que o vocabulário seja o único ponto de referência para comunicação, evitando sinônimos conflitantes.

3. Agrupados e invariantes: mantenha agregados pequenos e protegidos

Os agregados (agregado raiz e seus membros) são a unidade de consistência dentro de um contexto. Manter agregados grandes ou com muitos invariantes transacionais entre nós quebra a coesão do domínio e força a dependência de mecanismos de persistência de baixo nível.

Regras que eu sigo:

• Levo invariantes críticos para o agregado raiz e deixo que apenas operações do agregado modifiquem seu estado interno.
• Interações entre agregados ocorrem via domínio, preferencialmente com eventos de domínio ou comandos com confirmação assíncrona, mantendo consistência eventual quando necessário.
• Evito cópias translúcidas de dados entre agregados e prefiro estruturas simples, previsíveis e testáveis.

// Exemplo ilustrativo de agregado raiz (TypeScript)
class Pedido {
  private itens: ItemPedido[] = [];
  private status: 'aberto'|'pagando'|'finalizado' = 'aberto';

  adicionarItem(produtoId: string, quantidade: number, precoUnitario: number) {
    if (quantidade <= 0) throw new Error('Quantidade inválida');
    const existente = this.itens.find(i => i.produtoId === produtoId);
    if (existente) {
      existente.quantidade += quantidade;
    } else {
      this.itens.push(new ItemPedido(produtoId, quantidade, precoUnitario));
    }
  }

  calcularTotal(): number {
    return this.itens.reduce((acc, item) => acc + item.quantidade * item.precoUnitario, 0);
  }

  // invariantes protegidos dentro do agregado raiz
  fechar() {
    if (this.itens.length === 0) throw new Error('Pedido sem itens');
    this.status = 'finalizado';
  }
}

class ItemPedido {
  constructor(public produtoId: string, public quantidade: number, public precoUnitario: number) {}
}
      

4. Camadas, repositórios e isolamento: mantenha domínio separado da infraestrutura

É comum ver detalhes de persistência, integrações externas ou filas infiltrados na camada de domínio. Isso torna o código difícil de manter, testável e suscetível a mudanças de infra. A boa prática é manter o domínio isolado, deixando a infraestrutura responsável por persistência, integrações e mecanismos de comunicação.

• Organizo o código em camadas (Domínio, Aplicação, Infraestrutura) ou adotando uma arquitetura orientada a eventos, conforme o contexto.
• Defino repositórios como abstrações para acesso a dados, sem expor detalhes de implementação no domínio.
• Utilizo contratos simples para comunicação entre domínios e entre domínios e infra, preservando a testabilidade do núcleo de negócio.