1)Fundamentos do DDD: domínio, linguagem onipresente e contextos limitados

• Domínio: o conjunto de questões de negócio que o software deve resolver. O foco está no que importa para o negócio, não apenas na tecnologia.
• Modelo de domínio: abstração que registra as regras e a lógica de negócio de forma previsível e evolutiva. Evito “coding-for-scratch”; busco um modelo estável que reflita a realidade do domínio.
• Linguagem onipresente (Linguagem Ubíqua): termos, nomes de entidades e regras devem tornar-se uma linguagem compartilhada entre especialistas e desenvolvedores, reduzindo ruídos entre áreas.
• Contextos limitados (Bounded Contexts): fronteiras explícitas onde um modelo de domínio é consistente. Mapear contatos entre contextos é essencial para evitar ambiguidades.

Ao ler os livros, foco em como cada obra aborda a construção do modelo do domínio, a separação de responsabilidades e a governança entre contextos. Em termos práticos, isso se traduz na escolha de termos, regras e limites de mudança que guiam o design do software.

2) Estruturas táticas que aparecem nos guias centrais

• Entidades: objetos com identidade ao longo do tempo. Ocupam um papel estável no modelo mesmo com mudanças de estado.
• Value Objects: objetos imutáveis que representam tipos de valor (ex.: dinheiro, data). Evito mutabilidade inesperada.
• Aggregates: agregados como raízes de consistência. Toda alteração ocorre por meio de uma entidade raiz de agregado.
• Domain Events: eventos que registram algo que aconteceu no domínio, permitindo integração com outras partes do sistema sem acoplamento direto.
• Repositories: abstração de acesso a agregados, mantendo a lógica de construção/recuperação separada da lógica de negócios.
• Factories e Services de domínio: criação complexa de objetos e operações que não cabem em um único objeto com responsabilidade simples.

Para consolidar a ideia, apresento um exemplo mínimo de domínio em TypeScript que ilustra um agregado raiz (Order) com itens e um domínio de envio de evento.

// Exemplo simples de agregado Ordem com evento de domínio
export class OrderItem {
  constructor(public readonly productId: string, public readonly quantity: number, public readonly unitPrice: number) {}

  get total(): number { return this.quantity * this.unitPrice; }
}

export class Order {
  private items: OrderItem[] = [];
  private status: 'Draft' | 'Submitted' | 'Paid' = 'Draft';
  constructor(public readonly id: string) {}

  addItem(productId: string, qty: number, price: number): void {
    if (qty <= 0) throw new Error('Quantity must be positive');
    this.items.push(new OrderItem(productId, qty, price));
  }

  submit(): void {
    if (this.items.length === 0) throw new Error('Order has no items');
    this.status = 'Submitted';
    // emitir evento de domínio
    this.raiseEvent(new OrderSubmitted(this.id, new Date()));
  }

  getTotal(): number {
    return this.items.reduce((acc, it) => acc + it.total, 0);
  }

  private raiseEvent(event: DomainEvent): void {
    // armazenar em una coleção de eventos não confirmados
    // para simplificação, apenas log
    console.log('DomainEvent:', event);
  }
}

export interface DomainEvent { occurredAt: Date; }

export class OrderSubmitted implements DomainEvent {
  constructor(public readonly orderId: string, public readonly occurredAt: Date) {}
}

3) Visões críticas dos livros essenciais

• : visão fundamental. Explica o que é o DDD, o papel do modelo de domínio e a importância da linguagem onipresente. Ideal como leitura de fundamentação teórica e estratégica.
• Implementing Domain-Driven Design (Vaughn Vernon): foca na prática—táticas, padrões de implementação, e como orquestrar o domínio com arquiteturas mais tangíveis. Bom para quem quer traduzir o modelo em código de forma disciplinada.
• Domain-Driven Design Distilled (Vaughn Vernon): síntese prática dos conceitos, útil como guia rápido para revisitar os princípios centrais sem perder o fio condutor da modelagem de domínio.
• Patterns, Principles, and Practices of Domain-Driven Design (Scott Millett & Nick Tune): compêndio que aprofunda padrões, anti-padrões e cenários de aplicação. Excelente para aprofundar a parte de governança de contexto e padrões repetíveis.

Resumo estratégico: inicie pela visão de Evans para entender o que justificar como DDD; em seguida, avance para a prática com Vernon para consolidar a relação entre o modelo e o código; complemente com Millett & Tune para padrões mais maduros e com Domain-Driven Design Distilled para uma leitura rápida e direta.

4) Plano de leitura recomendado (4 semanas)

1. Semana 1 – Domain-Driven Design (Eric Evans): compreensão dos fundamentos, visão geral de linguagem onipresente e contextualização do domínio.
2. Semana 2 – Implementing Domain-Driven Design (Vaughn Vernon): foco em táticas, padrões de implementação e estratégias de separação entre contexto e código.
3. Semana 3 – Domain-Driven Design Distilled (Vaughn Vernon): revisões rápidas dos conceitos-chave para fixação prática.
4. Semana 4 – Patterns, Principles, and Practices of Domain-Driven Design (Millett & Tune): aprofundamento em padrões e governança de contexto com exemplos de aplicação.

Como aplico isso no meu dia a dia: leio um capítulo, anoto termos da linguagem onipresente, e traduzo cada conceito em ações no domínio real do negócio. Em seguida, faço pequenos protótipos para validar o modelo de domínio com a equipe de produto e engenharia.