Blog/Artigos · Engenharia
A linguagem ubíqua, os contextos delimitados, os padrões táticos de Eric Evans e quando a complexidade justifica todo esse esforço.
No começo do Gênesis, a primeira tarefa dada ao homem não é construir nem lutar: é nomear. Ele dá nome a cada criatura, e o nome fixa o entendimento, cria o vocabulário pelo qual o mundo pode ser pensado e comunicado. Sem nomes precisos, não há como falar do que existe. É exatamente esse o coração do Domain-Driven Design. A maior fonte de bug e retrabalho num projeto complexo não é técnica; é a distância entre o que o especialista de negócio quer dizer e o que o desenvolvedor entendeu e codificou. Quando o negócio diz apólice e o código diz contrato, quando um chama de cliente o que o outro chama de segurado, o software modela um mundo que ninguém pediu. DDD começa nomeando certo, para que todos falem a mesma língua.
Eric Evans, no livro azul que fundou o Domain-Driven Design em 2003, parte de uma observação simples e profunda: em sistemas de negócio, a complexidade difícil de domar não é a técnica, é a do próprio domínio. Um sistema de seguros, de logística, de crédito, carrega regras intrincadas, exceções, vocabulário próprio, que o especialista domina e o desenvolvedor precisa capturar. Quando o time trata isso como detalhe e foca só na técnica, o software fica tecnicamente elegante e comercialmente errado, porque modela mal o negócio que deveria servir.
DDD coloca o domínio no centro do esforço de design. Em vez de o modelo de dados espelhar tabelas de banco, o modelo de domínio captura os conceitos, as regras e o comportamento do negócio como o especialista os entende. Isso exige colaboração intensa entre quem conhece o negócio e quem escreve o código, e exige nomear com precisão, porque o nome é onde o entendimento se fixa. É por isso que a primeira tarefa do homem no Gênesis é a metáfora exata do DDD: antes de construir qualquer coisa, nomear o que existe, para que o software fale do mundo real com as palavras certas, e não com uma tradução torta que se perde a cada conversa entre negócio e técnica.
Cada tradução entre negócio e técnica perde um pouco do sentido. DDD elimina a tradução: o código fala a língua do domínio, e o entendimento para de vazar na conversa.
O conceito central do DDD é a linguagem ubíqua: um vocabulário único, compartilhado por desenvolvedores e especialistas de negócio, usado em toda parte, na conversa, na documentação e no código. Ubíqua quer dizer em todo lugar: o mesmo termo que o especialista usa na reunião é o nome da classe no código, sem tradução no meio. Se o negócio diz que uma apólice entra em vigência, então existe uma classe Apólice com um método entrarEmVigência, não um ContractManager com um setActiveFlag. O código vira legível para quem conhece o negócio, e a conversa entre as duas metades do time deixa de precisar de intérprete.
O ganho é que a linguagem ubíqua fecha a distância onde os bugs de entendimento nascem. Quando o código fala a língua do negócio, o especialista consegue ler o modelo e apontar o erro, cadê o caso de apólice suspensa?, antes de virar bug em produção. E quando surge uma ambiguidade na língua, o mesmo termo usado com dois sentidos, isso não é ruído a ignorar, é um sinal de que há dois conceitos distintos que precisam de nomes distintos, ou dois contextos diferentes. A linguagem ubíqua não é enfeite; é a ferramenta de precisão que transforma o entendimento do negócio em código fiel, e é a base sobre a qual todo o resto do DDD se ergue.
| Termo do negócio | Código sem DDD | Código com linguagem ubíqua |
|---|---|---|
| Apólice entra em vigência | contract.setActiveFlag(true) | apolice.entrarEmVigencia() |
| Segurado aciona sinistro | claim.create(userId) | segurado.acionarSinistro() |
| Cobertura expira | policy.status = 3 | cobertura.expirar() |
| Prêmio em atraso | invoice.overdue = true | premio.marcarEmAtraso() |
A grande sacada estratégica do DDD é o contexto delimitado, o bounded context. Num sistema grande, tentar uma única linguagem ubíqua para tudo fracassa, porque a mesma palavra significa coisas diferentes em partes diferentes do negócio. Cliente para o time de vendas é um prospecto com histórico de contato; cliente para o time de faturamento é um CNPJ com limite de crédito; cliente para o suporte é um contrato ativo com tickets. Forçar um modelo único de Cliente que sirva aos três produz um monstro que não serve bem a ninguém. O contexto delimitado reconhece isso: cada contexto tem a sua própria linguagem ubíqua, coerente dentro de suas fronteiras.
Definir onde uma fronteira de contexto cai é a decisão de design mais importante do DDD estratégico, e o mapa de contextos descreve como os contextos se relacionam: quem depende de quem, onde um traduz o modelo do outro. Quando dois contextos precisam conversar, uma camada anticorrupção protege o modelo de um da contaminação pelo modelo do outro, traduzindo na fronteira para que o Cliente de vendas não force sua forma sobre o Cliente de faturamento. Essa fronteira de contexto é também, não por acaso, a melhor candidata a fronteira de microsserviço: um contexto delimitado bem definido, com sua linguagem coesa e seu modelo próprio, é uma unidade natural de autonomia, e é por isso que DDD e a decisão de dividir em serviços andam de mãos dadas.
Dentro de um contexto, o DDD oferece padrões táticos para modelar o domínio em código. A entidade é o objeto com identidade que persiste no tempo, uma apólice é a mesma apólice mesmo que seus dados mudem. O objeto de valor não tem identidade própria, é definido pelos seus atributos, um dinheiro de cem reais é igual a outro de cem reais, e é imutável. O agregado é o cluster de entidades e objetos de valor tratados como uma unidade de consistência, com uma raiz que controla o acesso, garantindo que as regras de invariância do negócio nunca sejam violadas por uma mudança parcial.
Completam o conjunto o repositório, que abstrai a persistência do agregado, dê-me a apólice de número tal, sem o domínio saber de banco; o serviço de domínio, para a lógica que não pertence naturalmente a nenhuma entidade; e o evento de domínio, que registra que algo relevante aconteceu no negócio, a apólice entrou em vigência, base para a arquitetura orientada a eventos. Esses padrões são o vocabulário de implementação do DDD, mas o aviso de Evans é firme: eles são meio, não fim. Encher o código de agregados e objetos de valor sem antes ter a linguagem ubíqua e os contextos certos é DDD de fachada, a cerimônia tática sem a substância estratégica que lhe daria sentido.
| Padrão | O que é | Exemplo no domínio de seguros |
|---|---|---|
| Entidade | objeto com identidade que persiste | a Apólice, a mesma ainda que os dados mudem |
| Objeto de valor | definido pelos atributos, imutável | o Prêmio de cem reais, igual a outro de cem |
| Agregado | cluster com raiz e consistência | Apólice e suas Coberturas, mudadas juntas |
| Repositório | abstrai a persistência do agregado | buscar a Apólice sem o domínio saber de banco |
| Evento de domínio | registra o que aconteceu no negócio | ApóliceEntrouEmVigência, base do event-driven |
DDD amadurece do jargão técnico ao domínio no centro, e o erro mais comum é começar pelo fim. Muitos times pegam os padrões táticos, agregados, objetos de valor, repositórios, e os aplicam a um domínio simples, produzindo cerimônia pesada sem o benefício, o DDD de fachada. O caminho maduro é o inverso: começar pelo estratégico, a linguagem ubíqua e os contextos delimitados, que dão retorno mesmo sem uma linha de código tático, e só descer ao tático onde a complexidade do domínio justifica. DDD estratégico vale quase sempre num negócio de regras ricas; DDD tático vale onde a complexidade é alta o bastante para pagar a cerimônia.
E DDD não serve a todo sistema. Domínio simples, CRUD sobre dados sem regra intrincada, não precisa de DDD, e forçá-lo é afogar a simplicidade em modelagem. DDD brilha onde a complexidade do domínio é o desafio central, e é lá que ele se conecta com o resto deste eixo: a linguagem ubíqua é o vocabulário compartilhado que os design patterns também buscam; a Clean Architecture é a moldura que abriga o modelo de domínio no núcleo protegido; e o contexto delimitado é a fronteira que decide onde um monólito se divide em serviços. Nomear certo, a primeira tarefa do Gênesis, é a primeira tarefa do design de qualquer sistema complexo, porque o que não tem nome preciso não pode ser pensado, comunicado nem construído direito.
Domain-Driven Design começa onde o Gênesis começa: dando nomes. A linguagem ubíqua fecha a distância entre o que o negócio diz e o que o código faz, os contextos delimitados reconhecem que a mesma palavra tem sentidos diferentes em partes diferentes, e os padrões táticos dão a forma em código, mas são meio, não fim. O caminho maduro começa pelo estratégico e desce ao tático só onde a complexidade paga a cerimônia, e DDD só vale onde a complexidade do domínio é o desafio central. A IA extrai a língua e revela as costuras. Mas modelar o domínio continua sendo trabalho de quem o entende, porque o que não tem nome preciso não se constrói direito.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Engenhariaפָּרֹכֶת
Banco, framework e interface mudam o tempo todo; a regra de negócio deveria mudar só quando o negócio muda. Clean Architecture põe uma cortina entre o núcleo e o exterior: as dependências apontam só para dentro, e o detalhe fica de fora, trocável sem tocar no que importa.
Engenhariaשָׂפָה אֶחָת
O mercado oscilou do monólito para microsserviços e de volta para o monólito modular. Espalhar em serviços dá autonomia e cobra um imposto pesado de rede, consistência e operação. A pergunta madura não é qual está na moda, é quando o preço de espalhar se paga.
