O que é DDD e a linguagem ubíqua

Resumo

Domain-Driven Design (DDD) é modelar o software espelhando o negócio: o código fala a mesma língua dos especialistas do domínio. Antes dos padrões táticos, é preciso entender o domínio, seus subdomínios e a linguagem ubíqua.

1. Objetivos de Aprendizagem#

• Entender o que DDD resolve — e quando não vale a pena.
• Distinguir o DDD estratégico do tático.
• Reconhecer a linguagem ubíqua e refleti-la no código.

2. Pré-requisitos#

• Web API e Onion Architecture (Módulo 03).
• Classes, propriedades e encapsulamento (Aula 5.1).

3. Conceito#

DDD é uma abordagem para software de domínio complexo: em vez de organizar o código por detalhes técnicos, você o organiza em torno do negócio. A premissa central é que devs e especialistas do domínio devem compartilhar o mesmo vocabulário — e esse vocabulário deve aparecer no código.

DDD tem dois lados:

• Estratégico (o mapa): identifica o domínio (o problema do negócio) e seus subdomínios:
  • Core — o que diferencia o negócio (ex.: a precificação de um catálogo). É onde vale investir.
  • Supporting — apoia o core, mas não é o diferencial (ex.: cadastro de categorias).
  • Generic — resolvido igual em qualquer lugar (ex.: autenticação — use uma solução pronta). Também define os bounded contexts: fronteiras onde um termo tem um significado único.
• Tático (as ferramentas): entidades, value objects, agregados, repositórios, domain services e domain events — o assunto das próximas aulas.

A linguagem ubíqua é o coração do DDD: um vocabulário compartilhado entre time técnico e especialistas, sem tradução. Se o negócio diz "reajustar preço", o código tem produto.Reajustar(...) — não UpdateProdutoService.SetPreco(...).

Quando NÃO usar DDD: um CRUD simples (cadastro sem regras) não precisa de agregados nem value objects. DDD paga o próprio custo apenas onde há regras de negócio ricas. Aplicá-lo a tudo é over-engineering.

4. Mão na Massa#

Vamos usar o domínio deste curso — um catálogo — como exemplo contínuo. Antes de escrever código, mapeie a linguagem com o "especialista":

A regra prática: substantivos do negócio viram tipos; verbos viram métodos. Se um termo não existe no código, ou existe com outro nome, a linguagem ubíqua foi quebrada.

// Fala a língua do negócio: o método É a operação "reajustar".
produto.Reajustar(0.10m);   // aumenta 10%

// NÃO fala: expõe o "como" técnico, não o "o quê" do negócio.
produto.Preco = produto.Preco * 1.10m;

5. Exemplo Completo#

Modelar o catálogo com DDD começa por perguntas de negócio, não técnicas: o que é um preço válido? quem pode reajustar? um produto sem categoria existe? As respostas viram invariantes (regras sempre verdadeiras) que o modelo vai proteger — o oposto de um saco de get; set; manipulado por fora.

6. Boas Práticas e Armadilhas#

7. Segurança e Produção#

• Um modelo alinhado ao negócio reduz mal-entendidos que viram bugs caros. As regras ficam num só lugar (o domínio), facilitando auditoria e evolução.

8. Exercícios#

• Fácil: liste 5 substantivos e 5 verbos do domínio de um "carrinho de compras".
• Médio: classifique 3 subdomínios de um e-commerce em core/supporting/generic.
• Desafio: aponte, numa API CRUD que você conheça, um nome de classe que quebra a linguagem ubíqua e proponha o nome do negócio.

9. Resumo#

DDD modela o software em torno do negócio. O estratégico define domínio, subdomínios e fronteiras; a linguagem ubíqua garante que o código fale a língua do especialista. Os padrões táticos vêm a seguir.

10. Próximos Passos#

Os primeiros blocos táticos: entidades e value objects.

11. Referências#

• Microsoft Learn — Projetando o modelo de domínio (DDD)
• Eric Evans — Domain-Driven Design (o "livro azul")
• Vaughn Vernon — Implementing Domain-Driven Design