Quando você começa a usar RFCs agnósticas à linguagem, para de discutir detalhe de framework cedo demais e passa a discutir o que realmente importa: domínio, contratos e decisões arquiteturais. Esse é o ponto em que DDD deixa de ser slide bonito e vira mecanismo de alinhamento entre produto, engenharia e operação.
O problema é que muita RFC técnica nasce contaminada pela primeira escolha de implementação. Aí a discussão degrada: em vez de decidir fronteiras, invariantes e fluxos, o time debate sintaxe, biblioteca e preferência pessoal. A transformação real aqui é simples de descrever e difícil de operar: escrever RFCs que sobrevivem à troca de stack, preservam o modelo de negócio e reduzem retrabalho quando o sistema cresce.
Se a sua RFC morre quando a linguagem muda, ela nunca descreveu o sistema; só descreveu uma implementação temporária.
RFCs independentes de linguagem: por que isso muda a qualidade da decisão
Uma RFC independente de linguagem força o time a explicitar o que é estrutural e o que é acidental. Estrutural é regra de negócio, limite de contexto, contrato entre serviços, evento relevante, política de consistência. Acidental é se isso vai sair em Go, TypeScript, Python ou Java. Quando os dois níveis se misturam, a decisão nasce fraca.
Na prática, esse tipo de RFC melhora a conversa entre perfis diferentes. Produto entende impacto de regra e fluxo. Engenharia entende consequência de arquitetura. Comercial e operação conseguem ver onde existe risco de SLA, custo e gargalo. O documento para de ser artefato de um dev para outros devs e vira instrumento de coordenação.
Tem outro ganho que quase ninguém fala com honestidade: RFC agnóstica reduz ego técnico na mesa. Quando você remove o glamour da linguagem favorita, sobra a pergunta certa: isso modela bem o domínio? Muita discussão barulhenta desaparece aí. Não porque o problema ficou simples, mas porque a superfície da vaidade diminuiu.
Isso é especialmente relevante em times pequenos operando várias frentes ao mesmo tempo. Se você está entre código, comercial, produto e suporte, não pode reescrever decisão toda vez que a stack muda. Você precisa de um artefato que continue válido enquanto a operação roda 24/7. Esse é o trabalho da RFC bem feita.
DDD em RFCs agnósticas: onde o domínio entra de verdade
Falar de DDD em RFC sem cair em abstração vazia exige uma disciplina: começar por ubiquitous language, contexto e invariantes, não por classes e repositórios. O documento precisa nomear entidades, eventos, comandos e políticas do negócio com precisão. Se o nome está frouxo, a implementação vai divergir cedo.
Uma RFC boa descreve o bounded context com clareza operacional. O que pertence a esse contexto? O que fica fora? Quais decisões podem ser tomadas localmente e quais dependem de outro domínio? Sem isso, o sistema vira uma massa onde tudo consulta tudo e ninguém sabe quem é dono de quê.
Também é aqui que entram os padrões, mas do jeito certo. Não como catálogo decorado, e sim como vocabulário de decisão. Aggregate serve para proteger invariantes. Domain event serve para propagar mudança relevante sem acoplamento desnecessário. Anti-corruption layer serve para impedir que um modelo ruim contamine outro. O padrão só tem valor quando resolve uma tensão real do domínio.
O erro clássico é usar DDD para sofisticar sistema simples ou para mascarar falta de clareza. Se o domínio ainda não está entendido, a RFC precisa admitir isso. Honestidade técnica economiza mais tempo do que pseudoelegância. Melhor registrar hipótese, risco e critério de validação do que fingir certeza onde ela não existe.
Como estruturar uma RFC agnóstica à linguagem sem virar documento genérico
Ser agnóstica à linguagem não significa ser vaga. Pelo contrário. A RFC precisa ser específica no comportamento e abstrata na implementação. Essa distinção parece pequena, mas muda tudo. Você não escreve “usar fila X com framework Y”; você escreve a garantia necessária, o modo de falha aceitável e a expectativa de processamento.
Uma estrutura que funciona bem costuma seguir uma ordem rígida: contexto, problema, objetivos, não objetivos, modelo de domínio, contratos, fluxos, riscos, alternativas e critérios de aceitação. Isso mantém a conversa centrada no sistema, não no gosto pessoal de quem implementa. E cria histórico de decisão reaproveitável.
Se quiser um teste simples, pergunte: alguém competente em outra stack conseguiria implementar isso sem me chamar para decodificar intenção? Se a resposta for não, sua RFC ainda está presa demais à sintaxe mental da linguagem atual. O documento precisa transferir decisão, não só preferência técnica.
- Separe. Diferencie regra de negócio de detalhe de infraestrutura em seções distintas, sem misturar contrato com biblioteca.
- Nomeie. Defina entidades, eventos, comandos e estados com termos do domínio, não com nomes herdados do banco ou do framework.
- Descreva. Especifique invariantes, políticas de consistência e comportamento em falha de forma testável.
- Compare. Registre alternativas descartadas e o motivo da rejeição, para evitar rediscussão infinita semanas depois.
- Valide. Feche a RFC com critérios observáveis de sucesso, não com frases genéricas sobre escalabilidade e flexibilidade.
Esse formato evita dois extremos ruins: o documento abstrato demais, que não orienta ninguém, e o documento preso demais à implementação, que envelhece em semanas. RFC boa é a que continua útil depois que a primeira versão entra em produção e a realidade começa a bater no desenho original.
Padrões de arquitetura que sobrevivem à troca de stack
Quando falamos em padrões arquiteturais dentro de RFCs agnósticas, o foco precisa estar no comportamento que permanece estável mesmo se a stack mudar. Exemplo: idempotência, outbox, retry com backoff, segregação de leitura e escrita, versionamento de contrato. Nada disso depende de uma linguagem específica para fazer sentido.
O valor desses padrões está em comprimir experiência operacional em decisões reutilizáveis. Você não precisa redescobrir toda vez que eventos podem duplicar, que integrações quebram ou que consistência forte tem custo. A RFC registra a resposta escolhida para tensões recorrentes. Isso reduz improviso e melhora previsibilidade.
Mas aqui entra a parte brutalmente honesta: padrão também vira muleta. Muita gente invoca CQRS, event sourcing ou saga antes de provar a necessidade. Resultado: um sistema mais difícil de operar, observar e explicar. Em RFC séria, padrão não entra por prestígio intelectual. Entra porque existe uma restrição concreta que ele resolve melhor do que as alternativas.
Outra vantagem de manter o padrão no nível de decisão e não de ferramenta é a portabilidade organizacional. Você consegue trocar equipe, linguagem ou fornecedor sem destruir a memória arquitetural. O ativo real deixa de ser “quem lembra como fizemos em framework tal” e passa a ser “por que o sistema foi desenhado assim”.
Erros comuns ao escrever RFCs neutras em linguagem e como evitar retrabalho
O primeiro erro é confundir neutralidade com ausência de compromisso. Uma RFC agnóstica precisa tomar decisões duras: quem é dono do dado, onde a consistência é obrigatória, que evento dispara qual processo, quais limites de latência são aceitáveis. Se isso não está claro, o documento só empurra ambiguidade para a implementação.
O segundo erro é escrever para impressionar tecnicamente, não para coordenar execução. Isso aparece em diagramas bonitos sem consequência prática, termos sofisticados sem definição e listas de padrões sem vínculo com o domínio. Documento bom não é o que parece inteligente. É o que reduz erro de interpretação quando o time está cansado e a operação está pressionando.
O terceiro erro é ignorar o ciclo pós-RFC. Decisão sem observabilidade vira opinião congelada. Você precisa ligar o documento a sinais reais: taxa de falha, tempo de processamento, custo por fluxo, pontos de contenção, incidentes recorrentes. Sem esse retorno, a RFC não amadurece; ela vira arquivo morto com status de verdade.
Por fim, existe o erro mais caro: não registrar incerteza. Nem toda decisão nasce fechada. Às vezes a escolha correta é declarar hipótese, definir experimento e marcar revisão. Isso não é fraqueza. É maturidade operacional. O time que admite o que ainda não sabe tende a errar menos do que o time que finge convicção total cedo demais.
Perguntas frequentes sobre RFCs Agnósticas a Linguagem (DDD + Padrões)
O que é uma RFC agnóstica à linguagem na prática?
É um documento técnico que descreve domínio, contratos, fluxos, invariantes e decisões arquiteturais sem depender de uma linguagem específica. Ele orienta a implementação em qualquer stack competente, porque preserva intenção e comportamento, não sintaxe.
Como usar DDD dentro de uma RFC sem deixar o texto abstrato demais?
Comece pelo vocabulário do domínio, pelos bounded contexts e pelas invariantes que o sistema precisa proteger. Depois conecte isso a comandos, eventos, políticas e contratos observáveis, evitando cair direto em classes, ORMs e frameworks.
RFC agnóstica à linguagem funciona em times pequenos ou só em empresas grandes?
Funciona especialmente bem em times pequenos com alta carga de contexto e múltiplas frentes rodando ao mesmo tempo. Ela reduz retrabalho, melhora handoff e impede que decisões estratégicas fiquem presas à cabeça de uma pessoa ou a uma stack temporária.
Quais padrões valem a pena registrar em uma RFC desse tipo?
Os que resolvem tensões reais do sistema: idempotência, outbox, versionamento de contratos, políticas de retry, segregação de responsabilidades e limites de contexto. O critério não é sofisticação, e sim utilidade operacional e clareza de decisão.
Como saber se minha RFC ainda está dependente demais da linguagem?
Faça um teste simples: um time experiente em outra stack conseguiria implementar o comportamento descrito sem pedir tradução conceitual? Se a resposta for não, provavelmente o documento ainda mistura demais regra de negócio com detalhe de implementação.