Uber DOMA: Como Camadas de Domínio Domaram a Explosão de Microsserviços

A Uber cresceu de um monólito Python para uma arquitetura de microsserviços ao longo de vários anos, impulsionada pela necessidade de escalar times independentes em múltiplos produtos — Rides, Eats, Freight, ATG. O resultado natural desse crescimento foi uma explosão de serviços: cada time criava o que precisava, quando precisava, sem uma visão global das dependências.

O sintoma mais visível era o que o time de engenharia chamou internamente de dependency hell: um serviço de pagamento chamando diretamente um serviço de mapeamento de rotas; um serviço de notificações acoplado a lógica de precificação; ciclos de dependência que tornavam deployments simples em eventos de coordenação complexos. Com 2.200+ serviços, nenhum engenheiro individual conseguia ter um mapa mental confiável do sistema.

O problema não era técnico na raiz — era organizacional. Conway's Law operando em escala máxima: a arquitetura do sistema espelhava a estrutura de comunicação dos times, que por sua vez era caótica porque cresceu organicamente sem uma taxonomia de responsabilidades. A solução precisava atacar os dois lados: estrutura técnica e estrutura organizacional simultaneamente.

Além do acoplamento, havia um problema de descoberta e reuso. Times criavam serviços duplicados porque não sabiam que a funcionalidade já existia em outro lugar. A ausência de um contrato explícito entre serviços significava que qualquer mudança interna podia — e frequentemente causava — quebras em cascata em consumidores que nunca deveriam ter acesso direto àquela implementação.

O DOMA introduz quatro conceitos centrais que, em conjunto, reconstroem a ordem em um ecossistema de microsserviços caótico.

1. Domínios (Domains): Um domínio é uma coleção de microsserviços que representam uma área de negócio coesa — Rides, Payments, Maps, Driver, etc. A granularidade não é arbitrária: segue as linhas de responsabilidade dos times (Conway's Law deliberadamente aplicada, não acidental). Cada domínio tem um owner claro, um roadmap independente e uma fronteira de responsabilidade explícita.

2. Camadas (Layers): Domínios são organizados em camadas hierárquicas. Camadas inferiores (plataforma, infraestrutura) não podem depender de camadas superiores (produto, experiência). Essa restrição unidirecional é a chave para eliminar ciclos de dependência. Na prática, a Uber definiu camadas como: Infrastructure → Platform → Business Domain → Product → Experience. Um serviço de Maps não pode depender de lógica de Rides; um serviço de Rides pode depender de Maps.

3. Layer Interface (Gateway de Domínio): Cada domínio expõe exatamente uma interface pública — o Layer Interface. Serviços internos ao domínio são completamente opacos para o mundo externo. Consumidores externos só podem interagir com o domínio através dessa interface, que funciona como um API Gateway interno. Isso cria um contrato estável: o domínio pode refatorar sua implementação interna livremente, desde que mantenha a interface.

4. Extensões (Extensions): Extensões são o mecanismo de customização sem modificação. Em vez de um consumidor fazer fork de um serviço ou adicionar lógica condicional no núcleo ("se produto X, então..."), ele registra uma extensão que é invocada em pontos específicos do fluxo do domínio. É essencialmente o padrão Strategy/Plugin aplicado em escala de plataforma. Isso foi crítico para a Uber porque produtos diferentes (Rides vs. Eats vs. Freight) precisam de comportamentos ligeiramente diferentes nos mesmos domínios base.

A combinação desses quatro elementos cria o que o artigo da Uber chama de "structured modularity" — modularidade com regras de composição explícitas, não apenas decomposição arbitrária. O resultado prático é que o grafo de dependências, antes um espaguete, passa a ter uma topologia de DAG (Directed Acyclic Graph) com camadas bem definidas.

Um aspecto que o artigo da Uber trata com seriedade e que muitas análises superficiais ignoram: DOMA não é apenas uma reorganização de código. É uma reorganização de responsabilidades e poder de decisão.

Antes do DOMA, qualquer time podia criar dependências em qualquer serviço. Isso parece democrático, mas na prática significava que ninguém era responsável por nada de forma abrangente. O time de Payments não podia refatorar seu serviço de billing sem coordenar com 40 consumidores diretos que tinham acoplamento com detalhes de implementação interna.

Com DOMA, o Layer Interface cria uma fronteira de propriedade clara. O time dono do domínio é o único árbitro de quais funcionalidades são expostas publicamente. Isso tem consequências políticas reais: times de produto que antes podiam "pular a fila" acessando serviços internos diretamente agora precisam negociar adições à interface pública com o time dono. Isso é atrito intencional — o tipo de atrito que força conversas sobre design em vez de gambiarra.

O mecanismo de extensões é particularmente inteligente do ponto de vista organizacional. Ele resolve o problema clássico de plataformas: como um serviço central atende às necessidades divergentes de múltiplos produtos sem se tornar um gargalo ou um acumulador de lógica condicional? A resposta do DOMA é inverter o controle — o domínio define os pontos de extensão, os produtos registram seus comportamentos específicos. O time de plataforma não precisa conhecer todos os casos de uso; os times de produto não precisam de acesso ao núcleo.

Isso também tem implicações para hiring e onboarding. Um engenheiro novo no time de Payments precisa entender apenas o domínio de Payments e suas interfaces com domínios adjacentes — não o sistema inteiro. A complexidade cognitiva é delimitada pela fronteira do domínio. Em um sistema com 2.200 serviços sem essa estrutura, o onboarding efetivo levava meses; com DOMA, o escopo de aprendizado inicial é drasticamente reduzido.

DOMA é frequentemente descartado como "coisa de Uber" — uma solução para uma escala que a maioria das empresas nunca atingirá. Essa leitura é equivocada. Os princípios são aplicáveis muito antes de você ter 2.200 serviços.

A explosão de microsserviços começa cedo. Na minha experiência, times de 30-50 engenheiros já sofrem com os sintomas que o DOMA resolve: dependências cruzadas não documentadas, duplicação de funcionalidades, onboarding lento. Você não precisa esperar 2.000 serviços para introduzir fronteiras de domínio.

Comece com o mapa de dependências, não com a reorganização. Antes de qualquer mudança estrutural, torne visível o que existe. Ferramentas como Backstage (CNCF) ou até um grafo simples gerado a partir dos logs do service mesh revelam os padrões de acoplamento. O mapa é o diagnóstico; DOMA é um tratamento possível.

O Layer Interface é aplicável mesmo sem microsserviços. Em monólitos modulares, o mesmo princípio se aplica: módulos expõem interfaces públicas explícitas, implementações internas são privadas. A diferença é que a fronteira é de pacote/módulo em vez de rede. O padrão é agnóstico ao estilo de deployment.

Extensões são o padrão correto para plataformas internas. Qualquer time que constrói uma plataforma interna enfrenta o dilema: ser genérico demais (inútil) ou específico demais (não reutilizável). O modelo de extensões do DOMA — define os pontos de variação, deixa os consumidores injetarem o comportamento — é a resposta correta para esse dilema e se aplica independentemente da escala.