O Teste de Reversibilidade

🌐 Também em 28 idiomas

English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagem gerada com IA

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês

Módulo 3 de 7 do capítulo Pensar como um arquiteto de dados, o primeiro capítulo do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: O modelo de dados é o esqueleto · Próximo: Arquitetura é a arte dos trade-offs

A pergunta que este módulo responde: Como distinguir uma decisão de arquitetura de uma decisão comum?

Arquitetos tomam muitas decisões.

Mas nem toda decisão é uma decisão de arquitetura.

Essa é uma distinção importante. Se tratarmos toda decisão como arquitetura, passaremos todo o nosso tempo debatendo coisas relativamente fáceis de mudar. Se não reconhecermos as decisões que realmente são de arquitetura, podemos tomar hoje uma decisão de cinco minutos que leva cinco anos para desfazer.

Então como percebemos a diferença?

Gosto de fazer uma pergunta simples:

Quão difícil será reverter esta decisão depois?

Eu chamo isso de Teste de Reversibilidade.

Quanto mais difícil for reverter algo, e quanto mais outras coisas dependerem dele, mais atenção de arquitetura ele merece.

Algumas decisões são baratas de mudar

Vamos começar com algo simples.

Chamamos um campo de Categoria do cliente. Seis meses depois, o negócio decide que todo mundo na verdade chama aquilo de Segmento do cliente. Mudamos o rótulo. Pode haver documentação para atualizar e um pouco de treinamento, mas não é um grande evento de arquitetura. Teremos de conviver com o nome de API original, porém, porque mudá-lo tem consequências muito maiores. Então isso pode significar apenas lidar com uma mudança de rótulo, e com a confusão que ela pode trazer.

Tomamos uma decisão. Mudamos de ideia. Seguimos em frente.

Agora compare isso com outra decisão.

Estamos criando um identificador para clientes. Decidimos o que ele significa, que formato usa e qual sistema o cria. Depois o publicamos.

O Salesforce o usa. O data warehouse o usa. A plataforma de integração o usa. O portal do cliente o usa. Cinco outras aplicações começam a armazená-lo. Relatórios e pipelines de dados o usam. Talvez os clientes acabem vendo-o.

Três anos depois, alguém diz:

Provavelmente não devíamos ter projetado o identificador desse jeito.

Essa é uma conversa muito diferente.

A diferença não é que uma decisão seja mais técnica que a outra.

A diferença é a reversibilidade.

Veja como isso pode acontecer. Digamos que o negócio venha montando suas chaves com parte do nome do cliente mais um número. Funciona por anos, porque ninguém nunca precisou mudar um nome. Então, um ano depois ou mais, um nome muda, e de repente as chaves não batem com o padrão que o resto dos dados espera. Esse é um dos motivos pelos quais chaves não devem carregar nenhum significado intrínseco.

A arquitetura cria gravidade

Uma decisão de arquitetura tende a acumular coisas ao redor dela. Eu penso nisso como gravidade.

Escolha um modelo de objetos, e a automação é construída em torno dele.

Escolha uma chave, e outros sistemas começam a armazená-la.

Escolha onde os dados mestres vivem, e as integrações começam a fluir na direção deles e a partir deles.

Escolha um modelo de compartilhamento, e os processos de negócio começam a depender de quem pode ver o quê.

Escolha um padrão de integração, e os sistemas começam a depender do seu tempo e do seu comportamento.

Quanto mais essas decisões existem, mais gravidade desenvolvem. Em algum momento, mudar a decisão original significa mudar tudo o que se acumulou em torno dela.

A IA também sente essa gravidade. Uma ferramenta de IA trabalha a partir do que já está no sistema: quando um elemento-chave de design está lá, toda interação de IA depois disso trata esse elemento como fato e continua construindo sobre ele, e construindo, e construindo. A decisão ecoa adiante por muitas outras decisões, e nenhum humano jamais volta para revisitar a original. Cada geração aumenta a gravidade.

É por isso que o modelo de dados ser “o esqueleto” importa. Não somos cuidadosos porque mudar é ruim. Somos cuidadosos porque as dependências tornam a mudança cara.

Faça duas perguntas

Quando olho para uma decisão de design, faço duas perguntas:

Quão difícil é reverter isso?

Quanto vai depender disso?

Elas se relacionam, mas não são idênticas. Algo pode ser tecnicamente fácil de mudar e ter centenas de consumidores. As pessoas costumavam renomear objetos padrão para ficar mais claro, Conta como “Cliente”, por exemplo. Fácil de fazer. Depois outro sistema quis usar Contas para Parceiros, e não conseguiu. Outra coisa pode ter poucos consumidores e precisar de uma migração enorme para mudar, como o nome de API de um objeto referenciado em muitos lugares internamente. Ninguém de fora o vê, mas um nome errado continua confundindo a equipe. Os dois casos merecem atenção.

Pense em algumas decisões de dados comuns:

• Qual objeto do Salesforce representa este conceito de negócio?
• Qual é o identificador único?
• Qual sistema é o sistema de registro?
• Estes dados são copiados para o Salesforce ou acessados em outro lugar?
• Isto é um objeto ou vários objetos relacionados?
• Quem é dono dos dados, e por quanto tempo os guardamos?
• Quais são nossos limites de acesso padrão?
• Como esses dados se movem entre sistemas?

Isso é muito diferente de decidir onde um campo aparece numa página Lightning. O design de página também importa. O custo de errar é diferente.

Click to enlarge

Pense no raio de impacto

Outra forma de pensar a reversibilidade é o raio de impacto: se eu mudar esta decisão, o que mais se move?

Suponha que algo que modelamos como campo precise virar um objeto filho. Isso não é só uma mudança de esquema. O que acontece com os dados existentes? Com os relatórios, as integrações que esperam aquele campo, o Apex e os Flows que o referenciam, a segurança, as análises, um agente de IA cujas ações dependem da estrutura original?

Quanto maior o raio, mais cuidado devemos ter ao tomar a decisão original.

É também por isso que arquitetos precisam olhar além da sua própria parte do sistema. De dentro do Salesforce, uma mudança pode parecer fácil. Da perspectiva da empresa, ela pode afetar outros doze sistemas.

Decisões da empresa e decisões do Salesforce

Um arquiteto de dados pensa em dois níveis.

Dentro do Salesforce, decidimos objetos, relacionamentos, chaves, volume, acesso, automação e como os dados se comportam na plataforma.

Em toda a empresa, fazemos perguntas mais amplas. Onde o Cliente realmente vive? Quem é dono do Produto? Qual sistema cria um Pedido? Qual é o nosso identificador oficial? Quais informações são copiadas entre sistemas, e quais ficam onde estão?

Os dois níveis precisam se conectar. Já vi implementações Salesforce em que o modelo interno fazia todo o sentido sozinho, mas não se encaixava na empresa ao redor. Isso não basta. As estruturas do Salesforce precisam ser representadas no nível da empresa, e as decisões da empresa precisam voltar para o Salesforce.

Arquitetura é uma via de mão dupla.

Click to enlarge

Desacelere nas decisões caras

Um perigo em tecnologia é que as decisões mais fáceis de implementar podem parecer as mais fáceis de tomar. Não são a mesma coisa.

Criar mais um objeto personalizado é fácil. Criar mais um campo é fácil. Conectar mais uma API está ficando mais fácil, e a IA torna tudo isso ainda mais fácil.

Mas a facilidade de implementação não nos diz quase nada sobre o custo da decisão de arquitetura.

Antes de uma decisão difícil de reverter, desacelere o suficiente para perguntar: Que problema estamos realmente resolvendo? Que alternativas consideramos? O que estamos assumindo? O que acontece quando o volume cresce, e quando o negócio muda? O que mais vai depender disso? O que acontece se estivermos errados?

Não precisamos de seis meses de revisão toda vez que criamos um objeto. Precisamos, sim, de reflexão proporcional ao custo de errar. Se é um objeto para um único departamento ou subsistema, você pode andar mais rápido. Se são dados de referência, um objeto central de cliente ou algo usado entre sistemas, tire um tempo para pensar bem.

Registre o porquê

Há outro problema com decisões importantes: as pessoas esquecem por que elas foram tomadas.

Alguém olha para uma arquitetura três anos depois e pergunta: “Por que alguém projetaria isso desse jeito?” Às vezes a resposta é que era um design ruim. Acontece. Mas às vezes havia um motivo muito bom: uma limitação da plataforma que não existe mais, uma exigência regulatória, outro sistema que não suportava a abordagem preferida, um trade-off aceito conscientemente para cumprir um prazo.

Se registramos apenas o que decidimos e não por quê, o próximo arquiteto não tem como saber.

Para decisões significativas, registre. Não precisa ser um documento de 50 páginas. Um registro de decisão útil pode ser bem pequeno:

Contexto: Que problema estamos resolvendo?

Opções: Que alternativas realistas consideramos?

Decisão: O que escolhemos?

Consequências: O que ganhamos, e do que estamos abrindo mão?

Responsável: Quem responde por esta decisão?

Revisão: Que motivo ou data deve nos fazer revisitá-la?

O valor não está no documento. O valor está em preservar o raciocínio.

E quando uma decisão muda, não apague a original. Substitua-a. A decisão que estava certa em 2027 pode não estar certa em 2030, porque os volumes, o negócio, o Salesforce e o nosso entendimento mudam. O que quero guardar é a história: este era o contexto, esta foi a decisão e o porquê, isto mudou, e isto é o que estamos decidindo agora. Isso vale muito mais do que fingir que sempre soubemos a resposta.

Click to enlarge

Além do exame: a IA encurta o tempo entre a decisão e a dependência. Uma ferramenta de IA pode propor um modelo de dados em segundos, e depois criar os objetos, a automação, o código de integração e a interface de usuário sobre ele. Uma decisão questionável costumava levar meses de desenvolvimento até que muita coisa dependesse dela; agora as dependências chegam quase de imediato. Então revise as decisões por baixo do resultado, não só o resultado. A IA pode ajudar: pode listar opções, desafiar suposições e rascunhar o registro de decisão. Mas o arquiteto continua decidindo, e quanto mais difícil for reverter a decisão, mais esse julgamento humano importa.

Saiba quais decisões importam

Uma das habilidades que quero que você desenvolva é saber onde gastar sua atenção.

Não transforme toda escolha de configuração em uma cúpula de arquitetura.

Mas não tome casualmente uma decisão com a qual a organização vai conviver pela próxima década.

Pergunte:

Quão difícil será reverter isso?

Quanto vai depender disso?

Se as respostas forem muito difícil e muita coisa, você provavelmente encontrou uma decisão de arquitetura.

Click to enlarge

Desacelere. Entenda o requisito. Explore as alternativas. Torne os trade-offs visíveis. Tome a decisão. E registre o porquê.

O objetivo da arquitetura não é tomar decisões que nunca possam mudar.

O objetivo é reconhecer as decisões em que mudar de ideia vai sair caro.

O que um arquiteto decide aqui

• Quais decisões são de arquitetura: difíceis de reverter, com muita coisa dependendo delas.
• Quanta atenção cada decisão recebe, na proporção do custo de errar.
• Quais decisões são registradas, com contexto, opções, consequências, responsável e ponto de revisão.
• Como as decisões do Salesforce se alinham com as da empresa.

Para saber mais

• Object Relationships Overview (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-09; reconsultado em 2026-10-12): em um relacionamento mestre-detalhes, o acesso e a propriedade do detalhe seguem o mestre, e excluir um mestre exclui seus detalhes.
• Considerations for Object Relationships (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-09; reconsultado em 2026-10-12): um relacionamento de pesquisa só pode ser convertido em mestre-detalhes quando todo registro tem um valor nele; a conversão muda o modelo de compartilhamento (para Controlado pelo pai), e o tipo de relacionamento decide quais tipos de relatório padrão ficam disponíveis.
• Roll-Up Summary Field (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-09; reconsultado em 2026-10-12): campos de resumo de totalização só existem em relacionamentos mestre-detalhes, e precisam ser excluídos antes que um mestre-detalhes possa virar um relacionamento de pesquisa.