Pensar como um arquiteto de dados

🌐 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

Guia de estudo do capítulo 1 do curso Data Architect. Leia primeiro os sete módulos; esta página ajuda você a verificar o que ficou.

Sobre este guia de estudo. Ele foi construído apenas a partir do conteúdo deste curso e da lista de objetivos publicada no guia do exame da Salesforce. Ele nunca se baseia em questões reais do exame e não afirma saber o que cai na prova. Se você já fez o exame, por favor não me envie as questões: o contrato de certificação proíbe compartilhá-las, e decorar respostas é, de qualquer forma, o jeito errado de se tornar arquiteto.

Este capítulo tem menos fatos de exame, e isso é proposital. Ele trata de como um arquiteto pensa, e nenhum objetivo do exame pertence só a ele. Mas o exame é construído a partir de cenários: um negócio, alguns números, uma restrição e várias respostas que poderiam funcionar. Os hábitos deste capítulo são a forma de ler esses cenários. Por isso a lista abaixo diz qual objetivo cada ponto apoia, em vez de afirmar que ele é cobrado diretamente.

Para o exame

Marque conforme avança. Cada item tem um link para onde é ensinado.

Ler um cenário como um arquiteto (apoia todos os objetivos)

• Separo o requisito real do design em que ele chegou (“precisamos dos campos Aprovador 2 e Aprovador 3” versus “precisamos registrar cada aprovação”). (Não apenas aceite o requisito)
• Procuro os requisitos implícitos que ninguém declarou: propriedade, atualidade, falha, retenção, acesso. (Procure os requisitos implícitos)
• Coloco números: volume por dia, por ano, com crescimento, e percebo quando mais um zero muda a resposta. (Conheça seus números)
• Entre várias respostas que funcionam, comparo o que cada uma ganha e do que abre mão com os requisitos e restrições declarados. (Saiba do que você está abrindo mão, As restrições mudam a resposta)
• Trato custo, licenciamento e limites como parte de saber se uma ferramenta se encaixa, não como um detalhe posterior. (As nove perguntas)

O modelo de dados (apoia DM-1)

• Consigo julgar um modelo por ele sustentar o negócio, conseguir crescer com ele e ter desempenho. (Sustentar. Crescer. Ter desempenho.)
• Consigo identificar um modelo plano demais (Campo 1, Campo 2, Campo 3), normalizado demais ou construído sobre o objeto padrão errado. (Plano demais, complicado demais ou simplesmente errado)
• Sei por que uma lista de opções serve para uma lista curta e estável, e um relacionamento de pesquisa serve para uma lista que não para de crescer ou chega por uma integração. (Muitas formas de resolver o problema)
• Sei que uma chave que carrega significado (parte de um nome, por exemplo) quebra quando esse significado muda. (Algumas decisões são baratas de mudar)

Mudar o que já existe (apoia DM-1 e SDM-2)

• Sei por que mudar o tipo de um campo, ou tornar Obrigatório um campo existente, pode quebrar coisas mais tarde, e por que a plataforma bloqueia uma mudança de tipo enquanto código ou flows fazem referência ao campo. (Cuidado ao mudar o esqueleto)
• Conheço o padrão acrescentar em vez de alterar, descontinuar em vez de surpreender, e sei que o Field Usage pode marcar um campo como candidato à descontinuação. (Cuidado ao mudar o esqueleto)
• Conheço os fatos do mestre-detalhes por trás do Teste de Reversibilidade: o acesso e a propriedade do detalhe seguem o mestre, excluir um mestre exclui seus detalhes, os campos de resumo de totalização exigem mestre-detalhes, e um relacionamento de pesquisa só se converte em mestre-detalhes quando todo registro tem um valor. (O Teste de Reversibilidade, Para saber mais)

Licenças e compartilhamento (apoia SDM-1)

• Sei que usuários de comunidade de alto volume (Customer Community entre eles) não têm papéis e não usam o modelo de compartilhamento, então o acesso vem de conjuntos de compartilhamento e grupos de compartilhamento, e o compartilhamento Apex não os alcança. (Um exemplo prático: compartilhamento Apex)

Falha (apoia MIG-1 e os capítulos de integração)

• Sei que “job concluído” não é o mesmo que os dados estão corretos, e como a reconciliação encontra os registros que não chegaram. (Sucesso parcial ainda é uma falha que você precisa entender)

Além do exame

O exame é o piso, não o teto. Estes são os hábitos deste capítulo de que um arquiteto precisa, quer alguma pergunta trate deles ou não.

• Alguém precisa segurar a planta. Arquitetura é tomar boas decisões com informação incompleta, e conhecer suas consequências.
• O modelo de dados é o esqueleto. Todo o resto é construído sobre ele.
• O Teste de Reversibilidade: quão difícil é reverter isto, e quanto vai depender disto?
• A arquitetura cria gravidade. São as dependências que tornam a mudança cara, não a mudança em si.
• Pense no raio de impacto, dentro do Salesforce e em toda a empresa. A arquitetura é uma via de mão dupla.
• Registre o porquê: contexto, opções, decisão, consequências, responsável, revisão. Substitua; não apague.
• Melhor em quê? Uma decisão abaixo do ideal pode fazer parte de uma arquitetura ideal, se você sabe que a está tomando.
• Tenha uma imagem do ideal, para saber em que direção você está se afastando dele, e por quê.
• Think Correct. Think Fast. (Pense certo. Pense rápido.) A velocidade vem do raciocínio feito antes do momento.
• Construa para hoje. Planeje para amanhã. Planeje para a falha. E use 30% de crescimento quando ninguém lhe der um número.
• Aprenda as nove perguntas, não só as respostas.
• A IA é um foguete propulsor. Gerar não é julgar, irreversível continua sendo irreversível, e revisão humana não é cerimônia. Confie, mas verifique.

Palavras para conhecer

Termo	Em uma linha
Decisão arquitetural	Uma decisão difícil de reverter, com muita coisa dependendo dela
Teste de Reversibilidade	Quão difícil é reverter isto, e quanto vai depender disto?
Gravidade	As dependências que se acumulam em torno de uma decisão ao longo do tempo
Raio de impacto	Tudo o mais que se move quando uma decisão muda
Registro de decisão	Contexto, opções, decisão, consequências, responsável e ponto de revisão, mantido curto
Trade-off	O que uma opção ganha, e do que abre mão para conseguir isso
Requisito implícito	Algo que o negócio espera sem pedir, como a recuperação quando uma carga falha
Número de Zeros do Steve	Um zero a mais no volume pode mudar a arquitetura inteira
Reconciliação	Comparar o que deveria ter acontecido com o que aconteceu, registro por registro
Descontinuar	Marcar algo como de saída e depois aposentá-lo de forma deliberada, em vez de alterá-lo no lugar
Usuário de alto volume	Um usuário de comunidade (Customer Community entre as licenças) sem papel, fora do modelo de compartilhamento
Expansão descontrolada do esquema	Objetos e campos que se acumulam porque eram baratos de criar, até que ninguém projetou o modelo

Teste-se

Cenários curtos no estilo do curso. Decida sua resposta antes de abrir.

1. Uma equipe de vendas pede os campos Aprovador 2 e Aprovador 3, cada um com uma data, na Oportunidade. O que você pergunta, e o que poderia construir?

Pergunte por quê, e quantas aprovações pode haver. Se puder haver mais de duas ou três, o requisito é registrar cada aprovação, não acrescentar campos: um objeto filho, um registro por aprovação. Releia Não apenas aceite o requisito.

2. Alguém quer renomear o rótulo de um campo, e outra pessoa quer mudar o formato do identificador de cliente que cinco sistemas já armazenam. Qual merece mais da sua atenção, e por quê?

O identificador. O rótulo é barato de mudar. O identificador reprova no Teste de Reversibilidade: difícil de reverter, e muita coisa já depende dele. Dedique atenção na proporção do custo de errar. Releia Algumas decisões são baratas de mudar.

3. Um campo de texto está em uso há anos. Agora o negócio quer que ele guarde um número. Qual é sua abordagem?

Não o altere no lugar. Descubra o que depende dele (Flows, Apex, relatórios, integrações, agentes) e o que acontece com os dados antigos. Normalmente: acrescente um campo novo, migre de forma deliberada e descontinue o antigo. Releia Cuidado ao mudar o esqueleto.

4. 1.200 locais, 100 agendamentos por local por dia, cerca de 305 dias por ano, dois registros por agendamento, cinco anos guardados, 30% de crescimento. Aproximadamente quantos registros, e por que isso importa?

Cerca de 73 milhões de registros no primeiro ano (36,6 milhões de agendamentos, dois registros cada), e mais de 650 milhões em cinco anos com o crescimento. Mesmo recurso, uns zeros a mais, uma arquitetura muito diferente. Releia Conheça seus números.

5. Uma carga noturna informa “concluído” para um milhão de registros. Como você sabe que funcionou?

Você reconcilia. O lado que recebe confirma cada registro que salvou; o remetente compara o que enviou com o que foi confirmado. Confirmações faltando significam que não funcionou, diga o que disser o status do job, e mostram quais registros tentar de novo, encaminhar a uma pessoa ou alertar. Releia Sucesso parcial ainda é uma falha que você precisa entender.

6. Uma comunidade de 15 milhões de usuários Customer Community precisa de acesso complexo a registros. Alguém propõe compartilhamento Apex. Qual é o problema?

São usuários de alto volume: sem papéis, fora do modelo de compartilhamento, então não há registro de compartilhamento para o Apex gravar. O acesso vem de conjuntos de compartilhamento e grupos de compartilhamento. A licença decidiu quais ferramentas de compartilhamento existem. Releia Um exemplo prático: compartilhamento Apex.

7. Uma ferramenta de IA gera vinte objetos para um novo app em minutos. Qual é o trabalho do arquiteto agora?

Decidir se deveríamos ter cinco. Entender o modelo bem o bastante para defendê-lo: por que esses objetos e relacionamentos, onde estão as chaves e os dados mestres, o que acontece em escala. Verificar os fatos em que ela se apoiou. Gerar não é julgar. Releia Implementação barata desloca o valor.

Para saber mais

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (em inglês, consultado em 2026-09-25): a lista oficial de objetivos e seus pesos. Sempre confira a versão atual antes de agendar o exame.