Domínio e Subdomínios

O domínio é a área do negócio para a qual o software existe, o conjunto de atividades, regras e
conhecimentos que geram valor para a organização. Em um e-commerce, o domínio cobre catálogo,
pedidos, pagamentos e logística; em um banco, cobre contas, crédito, risco e compliance.
Domain-Driven Design parte do princípio de que o retorno do software vem da fidelidade com que ele
modela esse domínio, e não da sofisticação da stack. Como negócios reais são grandes demais para
caber em um único modelo coerente, o DDD decompõe o domínio em subdomínios, fatias do negócio com
responsabilidade e nível de importância próprios. Essa decomposição é a primeira decisão
estratégica do projeto, porque define onde investir talento escasso e onde é aceitável comprar
solução pronta. Em produção, classificar mal esses subdomínios custa caro: times seniores alocados
em software commodity e modelos genéricos aplicados onde a empresa realmente se diferencia.

Domínio como área do negócio

O domínio vive no espaço do problema, não no espaço da solução. Ele existiria mesmo sem software:
um banco opera crédito e risco com ou sem sistema, e o software apenas automatiza e amplia essa
operação. Essa distinção importa porque a conversa com especialistas acontece no vocabulário do
negócio, enquanto a arquitetura técnica é apenas o meio de expressá-la. O arquiteto que confunde os
dois espaços desenha módulos em volta de tecnologias, como pastas genéricas de controllers e
services que atravessam todo o negócio, em vez de desenhar em volta de pedidos, crédito e
sinistros. A pergunta que abre o trabalho não é "quais frameworks usaremos", e sim "quais partes do
negócio este sistema atende". A resposta delimita o escopo do modelo e evita que o sistema se torne
um amontoado de funções sem fronteira.

Por que decompor em subdomínios

Um domínio inteiro, como o de um marketplace, contém dezenas de áreas com níveis de complexidade e
de importância muito diferentes. Tentar modelar tudo em um único modelo corporativo produz um
modelo gigante que ninguém domina por completo e que quebra a cada mudança local. Subdomínios
existem para reduzir essa carga cognitiva: cada fatia tem vocabulário próprio, especialistas
próprios e uma fronteira onde o modelo faz sentido. A decomposição também dialoga com a lei de
Conway, pois times entregam a arquitetura que espelha a estrutura da organização, e subdomínios bem
desenhados viram candidatos naturais a times e a serviços. Na prática, a pergunta operacional é
simples: onde termina a responsabilidade de um grupo de pessoas e começa a de outro. Essa fronteira
organizacional, validada com o negócio, é o candidato mais confiável a subdomínio.

Subdomínio central (core domain)

O core domain é a parte do negócio em que a empresa se diferencia da concorrência e onde o software
cria vantagem competitiva. É a área que justifica a existência do produto: o motor de precificação
dinâmica de um varejista, o algoritmo de concessão de crédito de um banco digital, o sistema de
matching de um aplicativo de mobilidade. Ele merece os melhores talentos, atenção de arquitetura
sênior e investimento pesado em testes e observabilidade, porque um defeito aqui tem impacto direto
em receita. Uma característica importante é que o core domain raramente é comprado pronto: se
qualquer concorrente pode adquirir a mesma solução, aquilo não diferencia ninguém. Identificar o
core domain exige conversa com a liderança e não é um trabalho estático, pois a vantagem competitiva
se move conforme o mercado amadurece.

Subdomínios de suporte (supporting subdomain)

Os subdomínios de suporte existem para viabilizar o core domain, mas não são a fonte de
diferenciação. No e-commerce, o cadastro de clientes e o fluxo de devoluções sustentam a operação,
porém nenhum cliente escolhe a loja por causa deles. A complexidade costuma ser moderada, com
regras próprias que variam entre empresas, o que impede a compra direta de prateleira. A estratégia
usual é construir com esforço controlado, frequentemente com times menores ou equipes
generalistas, e aceitar soluções mais simples do que as que o core receberia. O risco clássico é o
oposto do core: subestimar um supporting que cresceu em importância e continuar tratando-o como
atividade secundária enquanto ele já virou gargalo de produção. A revisão periódica da classificação
evita esse descolamento.

Subdomínios genéricos (generic subdomain)

Subdomínios genéricos são iguais em praticamente qualquer empresa do setor, ou até entre setores
diferentes. Autenticação, envio de e-mail, emissão de notas fiscais padronizadas e gestão de
permissões são exemplos típicos. Ninguém vence concorrência por ter um CRUD de usuários melhor, e a
existência de produtos maduros no mercado torna escrever esse código do zero um custo sem retorno.
A estratégia recomendada é comprar ou adotar open source, integrando por uma borda estreita, o que
reduz manutenção e tempo de chegada ao mercado. A ressalva de produção é escolher bem o ponto de
integração: um produto comprado mal isolado contamina o modelo do core com conceitos externos. O
ideal é colocar uma camada fina de tradução na borda, para que o vocabulário interno permaneça o do
negócio.

Exemplos de classificação em e-commerce e banking

A tabela a seguir compara os três tipos de subdomínio com critérios objetivos e exemplos reais dos
dois setores mais usados no estudo de DDD.

Note que a mesma função pode mudar de classe entre empresas. Logística é commodity para um
marketplace de produtos digitais e é core para uma transportadora, porque é exatamente nela que a
transportadora compete. A classificação é sempre relativa ao negócio da organização, nunca absoluta
ao sistema.

Mapeamento de subdomínio para time e serviço

Depois de classificar, o arquiteto traduz subdomínios em unidades de organização e de entrega. O
mapeamento mais saudável, quando o tamanho da empresa permite, é um time por subdomínio central e
grande, e times compartilhados para subdomínios menores, sempre com um responsável claro por cada
fatia. No código, cada subdomínio vira um módulo com pacote próprio, e em ambientes de
microsserviços vira um serviço ou um conjunto coeso de serviços. O código a seguir ilustra a
organização de módulos por subdomínio em um monólito modular de e-commerce, que é o ponto de
partida recomendado antes de qualquer extração para serviços.

ecommerce/
  precificacao/            # core domain: regras de preço e promoção
    dominio/
    aplicacao/
    infraestrutura/
  pedidos/                 # supporting: sustenta o funil de vendas
    dominio/
    aplicacao/
    infraestrutura/
  autenticacao/            # generic: commodity, candidato a produto pronto
    adaptador/             # borda estreita com o fornecedor externo

A regra de dependência é que módulos de suporte e genéricos podem depender de contratos publicados
pelo core, mas nunca o contrário. Se o módulo de precificação começa a importar classes de
autenticação, a fronteira quebrou e a extração futura de serviços ficará mais cara. Essa disciplina
de dependência, fiscalizada em revisão de código ou com ferramentas de análise estática, é o que
mantém o mapeamento vivo na base de código e não apenas em slides.

Revisando a classificação ao longo do tempo

Subdomínios não são gravados em pedra, pois a vantagem competitiva se desloca conforme o mercado e a
maturidade da empresa. Uma esteira de logística que era supporting pode virar core quando a empresa
passa a prometer entrega em horas como diferencial. Um sistema genérico comprado pode precisar de
internalização quando o fornecedor encerra o produto. Em revisões trimestrais de arquitetura, vale
perguntar três coisas: onde o negócio pretende competir no próximo ano, quais subdomínios geraram
incidentes com impacto em receita e onde o time sente que o modelo atual não dá conta. As respostas
realocam talento e ajustam fronteiras antes que o desalinhamento chegue à produção.

Erros comuns e boas práticas

• Tratar o sistema inteiro como core domain, sem hierarquia de importância. Isso dilui investimento
  e impede decisões de compra, pois tudo passa a parecer indispensável.
• Classificar pela dificuldade técnica, e não pelo que diferencia o negócio. Complexidade técnica
  alta em uma área commodity não a torna core.
• Mapear subdomínios para camadas técnicas, como um serviço só de validação ou só de persistência.
  Subdomínio é fatia vertical do negócio, com dados e comportamento juntos.
• Comprar um produto para o core domain por pressão de prazo. A diferenciação fica nas mãos de um
  fornecedor e o custo de mudança cresce sem retorno.
• Congelar a classificação do primeiro workshop e nunca revisá-la. Revisões periódicas mantêm o
  investimento alinhado à estratégia real da empresa.
• Distribuir um subdomínio entre vários times sem dono claro. Fronteira sem dono vira terra de
  ninguém em incidentes e acumula código órfão.