Domínios e subdomínios: classificação e decisões de investimento
Índice
- Domínio, subdomínio e Bounded Context
- Classificação estratégica
- Classificação não é decisão de fornecimento
- Processo recomendado
- Exemplo hipotético
- Registro da decisão
- Referências
Classificar um subdomínio como Core, Supporting ou Generic ajuda a discutir onde concentrar atenção e capacidade de engenharia. A classificação não determina, sozinha, se a solução deve ser construída, comprada ou terceirizada.
Uma mesma capacidade pode ser estratégica para uma organização e comum para outra. Também pode mudar de categoria quando a estratégia, o mercado, a regulação, a tecnologia disponível ou a capacidade operacional mudam. Por isso, a classificação deve registrar evidências, hipóteses e uma data de revisão.
Domínio, subdomínio e Bounded Context
Na referência de Domain-Driven Design, domínio é uma esfera de conhecimento, influência ou atividade. O domínio do software é a área à qual o usuário aplica o programa.
Um subdomínio é uma parte do espaço do problema. Separar o domínio em subdomínios ajuda a identificar capacidades, regras e conhecimentos com importância estratégica diferente.
Bounded Context pertence ao espaço da solução: delimita onde um modelo e sua linguagem são aplicáveis. Um subdomínio e um Bounded Context podem ter correspondência útil, mas ela não é obrigatoriamente um para um. Um subdomínio pode exigir mais de um contexto, e um sistema legado pode manter responsabilidades de vários subdomínios no mesmo contexto.
Classificação estratégica
As categorias abaixo são hipóteses sobre a importância atual de uma capacidade para a organização.
| Categoria | Pergunta principal | Características possíveis | Cuidado necessário |
|---|---|---|---|
| Core Domain | Em que capacidade a organização pretende se diferenciar ou aprender mais rápido? | Modelo específico, conhecimento escasso, mudança frequente ou impacto direto na estratégia | Nem toda lógica complexa ou fonte de receita é Core |
| Supporting Subdomain | Qual capacidade específica é necessária para viabilizar o negócio ou o Core sem constituir a diferenciação escolhida? | Regras próprias, integração importante ou processo interno particular | “Supporting” não significa dispensável nem baixa qualidade |
| Generic Subdomain | Qual capacidade resolve um problema amplamente conhecido, com modelos ou soluções reutilizáveis? | Linguagem consolidada, oferta de mercado ou pouca diferenciação local | “Generic” não significa simples, barato, sem risco ou compra obrigatória |
Complexidade e diferenciação ajudam a conversa, mas não produzem a categoria automaticamente. Autenticação, faturamento ou observabilidade podem ser genéricos para a estratégia e, ao mesmo tempo, possuir alto risco operacional. Um algoritmo complexo pode não ser Core se não sustentar uma diferença relevante para a organização.
O que observar
Para classificar um subdomínio, procure evidências em vez de atribuir uma nota intuitiva.
| Critério | Perguntas | Evidência possível |
|---|---|---|
| Diferenciação | A capacidade muda por que a organização compete ou cumpre sua missão? O usuário escolheria a solução por causa dela? | Estratégia documentada, pesquisa com usuários, análise competitiva, resultado de experimentos |
| Impacto | Quais resultados dependem da capacidade? O que acontece se ela falhar ou não evoluir? | Métricas de produto e operação, incidentes, perdas, obrigações contratuais |
| Especificidade do modelo | O conhecimento e as regras são particulares desta organização? Existe uma linguagem própria relevante? | Workshops de domínio, regras documentadas, variações em relação a soluções disponíveis |
| Mudança e incerteza | A equipe ainda precisa descobrir o modelo? As regras mudam com frequência? | Histórico de alterações, hipóteses abertas, retrabalho, roadmap |
| Mercado | Existem produtos, serviços, bibliotecas ou padrões que atendem aos requisitos? | Avaliação técnica atual, prova de conceito, referências de clientes comparáveis |
| Risco e regulação | Quais requisitos de segurança, privacidade, auditoria, disponibilidade ou soberania se aplicam? | Análise de risco, requisitos legais validados, políticas internas, SLA e RTO/RPO |
| Capacidade operacional | A organização consegue desenvolver, operar, proteger e manter a solução? | Competências da equipe, carga de suporte, orçamento, plantão, histórico de operação |
Ausência de evidência não deve ser convertida em certeza. Registre a classificação como provisória quando a estratégia ou o comportamento da capacidade ainda não estiverem claros.
Notas numéricas são opcionais
Uma escala pode ajudar a comparar percepções em um workshop, mas números sem rubrica apenas escondem opiniões.
Se a equipe decidir pontuar critérios:
- defina o significado de cada faixa antes da avaliação;
- associe cada nota a uma evidência ou hipótese identificada;
- registre quem participou e em qual data;
- examine divergências entre participantes, em vez de usar somente a média;
- teste se pequenas mudanças nas notas alterariam a decisão;
- não publique o resultado como diagnóstico universal do setor.
Quando esse método não estiver disponível, prefira avaliações qualitativas acompanhadas de justificativa.
Classificação não é decisão de fornecimento
Build, buy, adoção de open source, terceirização e reaproveitamento de legado são opções de fornecimento e operação. Elas respondem a outra pergunta: qual arranjo atende aos requisitos com custo, risco e capacidade aceitáveis?
As decisões podem ser combinadas. Um Core Domain pode usar banco, mensageria, modelos ou serviços adquiridos enquanto a equipe mantém internamente o conhecimento que produz diferenciação. Um Generic Subdomain pode ser construído quando não existe produto compatível, quando o custo total é menor ou quando requisitos de regulação, latência, integração ou reversibilidade impedem a compra.
Critérios para comparar opções
| Critério | O que comparar |
|---|---|
| Adequação | Cobertura dos requisitos essenciais e custo das lacunas |
| Diferenciação | Qual parte do conhecimento ou comportamento precisa permanecer sob controle da organização |
| Custo total | Licença, desenvolvimento, integração, migração, operação, suporte, segurança e saída |
| Tempo e reversibilidade | Prazo para aprender ou entregar, custo de trocar a decisão e dependência de roadmap externo |
| Risco | Segurança, privacidade, disponibilidade, continuidade do fornecedor e concentração operacional |
| Regulação | Evidências de conformidade, auditoria, localização de dados, retenção e responsabilidades contratuais |
| Capacidade operacional | Pessoas, competências, observabilidade, resposta a incidentes e manutenção de longo prazo |
| Integração e dados | Contratos, qualidade, portabilidade, sincronização, ownership e consistência dos dados |
Trade-offs por opção
| Opção | Pode fazer sentido quando | Custos e riscos a verificar |
|---|---|---|
| Construir internamente | O comportamento é diferenciador, a solução disponível não atende ou o aprendizado precisa ficar na equipe | Tempo, manutenção contínua, segurança, operação e custo de oportunidade |
| Comprar um produto ou SaaS | A capacidade está madura no mercado e a solução atende aos requisitos essenciais | Lock-in, integração, migração, preço futuro, acesso aos dados e dependência do fornecedor |
| Adotar open source e operar | A solução reduz desenvolvimento sem transferir o controle operacional | Atualizações, vulnerabilidades, conhecimento interno, infraestrutura e suporte |
| Terceirizar desenvolvimento ou operação | Falta capacidade interna temporária ou a especialização externa reduz um risco conhecido | Retenção de conhecimento, governança, contratos, transição e dependência da equipe externa |
| Reaproveitar legado | A capacidade existente atende ao objetivo e substituí-la custa mais do que integrá-la com limites claros | Restrições de mudança, acoplamento, obsolescência, suporte e estratégia de saída |
Nenhuma linha da tabela é uma recomendação automática. A opção escolhida precisa ser comparada com os requisitos e as restrições do caso.
Processo recomendado
1. Mapear o problema sem escolher produto
Liste capacidades e regras na linguagem do negócio. Evite começar por nomes de sistemas, equipes ou fornecedores, pois eles descrevem a solução atual e podem esconder limites diferentes no problema.
2. Declarar a estratégia e o horizonte
Registre qual resultado a organização pretende diferenciar, proteger ou melhorar e em qual horizonte a decisão será avaliada. Sem essa informação, Core tende a significar apenas “importante” ou “complexo”.
3. Classificar com evidências e incertezas
Para cada subdomínio, registre categoria proposta, evidências, hipóteses contrárias e perguntas abertas. Divergência entre participantes é informação para investigação, não um erro a eliminar por votação.
4. Comparar opções de fornecimento separadamente
Só depois da classificação, compare construir, comprar, adotar, terceirizar ou manter o legado. Use os mesmos requisitos essenciais e o mesmo horizonte de custo para todas as alternativas.
5. Definir limites e responsabilidades
Identifique quem decide sobre o modelo, quem opera a solução, quem responde por incidentes, quais dados ficam sob qual ownership e como a organização poderá sair da escolha.
6. Revisar por sinais observáveis
Reavalie a decisão quando ocorrer uma mudança relevante, como nova estratégia, produto de mercado viável, exigência regulatória, aumento de incidentes, custo incompatível ou perda de capacidade interna. A revisão não precisa esperar um calendário fixo quando esses sinais já estiverem presentes.
Exemplo hipotético
Considere uma plataforma de entregas cuja estratégia declarada seja oferecer previsões mais confiáveis em regiões atendidas por transportadores locais. O cenário é didático; não descreve uma empresa observada nem recomenda produtos.
| Capacidade | Hipótese de classificação | Alternativas a avaliar | Evidência que falta |
|---|---|---|---|
| Previsão de prazo | Core, se a qualidade da previsão sustentar a diferenciação declarada | Modelo interno com componentes de dados adquiridos ou open source | Impacto da previsão na escolha e retenção dos clientes |
| Cadastro de transportadores | Supporting, se exigir regras locais sem diferenciar a oferta | Workflow configurável, implementação simples ou serviço existente | Variação real das regras e custo de integração |
| Gestão de identidade | Generic, se os requisitos forem atendidos por modelos consolidados | SaaS, open source operado ou solução corporativa existente | Requisitos de segurança, residência de dados, integração e custo total |
| Notificações de entrega | Generic ou Supporting, conforme a linguagem e os fluxos específicos | Serviço de comunicação com uma camada local de regras | Necessidade de personalização e criticidade operacional |
Mesmo nesse cenário, Core não significa “construir tudo”. O conhecimento sobre previsão pode permanecer interno enquanto infraestrutura e capacidades auxiliares são adquiridas. Da mesma forma, classificar identidade como Generic não autoriza contratar um fornecedor antes de avaliar risco, regulação, integração e operação.
Registro da decisão
Use um registro curto para tornar a análise revisável:
1
2
3
4
5
6
7
8
9
10
11
12
13
subdomain:
business_outcome:
classification: core | supporting | generic | provisional
evidence:
assumptions:
open_questions:
constraints:
supply_options_considered:
decision:
consequences:
owner:
decision_date:
review_signals:
O registro não substitui pesquisa, modelagem ou análise jurídica. Ele torna visível a base usada para decidir e ajuda a identificar quando essa base deixou de ser válida.
Referências
- Eric Evans: Domain-Driven Design Reference
- DDD Crew: Bounded Context Canvas
- Eric Evans — Domain-Driven Design: Tackling Complexity in the Heart of Software
- Vaughn Vernon — Implementing Domain-Driven Design
- Vlad Khononov — Learning Domain-Driven Design