Pensar como um arquiteto de dados

🌐 Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 com IA. Ainda não revisto 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-o a verificar o que ficou.

Sobre este guia de estudo. Foi construído apenas a partir do conteúdo deste curso e da lista de objetivos publicada no guia do exame da Salesforce. Nunca se baseia em perguntas reais do exame e não afirma saber o que sai na prova. Se já fez o exame, por favor não me envie as perguntas: o contrato de certificação proíbe partilhá-las, e decorar respostas é, de qualquer forma, a maneira errada de se tornar arquiteto.

Este capítulo tem menos factos de exame, e isso é propositado. Trata de como um arquiteto pensa, e nenhum objetivo do exame lhe 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 que objetivo cada ponto apoia, em vez de afirmar que é avaliado diretamente.

Para o exame

Marque à medida que 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 chegou («precisamos dos campos Aprovador 2 e Aprovador 3» versus «precisamos de registar 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)
• Ponho números: volume por dia, por ano, com crescimento, e percebo quando mais um zero muda a resposta. (Conheça os seus números)
• Entre várias respostas que funcionam, comparo o que cada uma ganha e de que abdica com os requisitos e restrições declarados. (Saiba de que está a abdicar, As restrições mudam a resposta)
• Trato custo, licenciamento e limites como parte de saber se uma ferramenta encaixa, não como um pormenor posterior. (As nove perguntas)

O modelo de dados (apoia DM-1)

• Consigo julgar um modelo por 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 porque é que uma lista de opções serve para uma lista curta e estável, e uma relação 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) se parte quando esse significado muda. (Algumas decisões são baratas de mudar)

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

• Sei porque é que mudar o tipo de um campo, ou tornar Obrigatório um campo existente, pode estragar coisas mais tarde, e porque é 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 factos da mestre-detalhe por trás do Teste de Reversibilidade: o acesso e a propriedade do detalhe seguem o mestre, eliminar um mestre elimina os seus detalhes, os campos de resumo de totalização exigem mestre-detalhe, e uma relação de pesquisa só se converte em mestre-detalhe quando todos os registos têm um valor. (O Teste de Reversibilidade, Para saber mais)

Licenças e partilha (apoia SDM-1)

• Sei que os utilizadores de comunidade de grande volume (Customer Community entre eles) não têm funções e não usam o modelo de partilha, por isso o acesso vem de conjuntos de partilha e grupos de partilha, e a partilha Apex não os alcança. (Um exemplo prático: partilha 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 registos que não chegaram. (Um sucesso parcial continua a ser uma falha que precisa de entender)

Além do exame

O exame é o chão, 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 de segurar a planta. Arquitetura é tomar boas decisões com informação incompleta, e conhecer as 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 dois sentidos.
• Registe 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 souber que a está a tomar.
• Tenha uma imagem do ideal, para saber em que direção se está a afastar dele, e porquê.
• Think Correct. Think Fast. (Pense certo. Pense rápido.) A velocidade vem do raciocínio feito antes do momento.
• Construa para hoje. Planeie para amanhã. Planeie 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 é o propulsor do foguetão. Gerar não é julgar, o irreversível continua a ser irreversível, e a revisão humana não é uma cerimónia. Confie, mas verifique.

Palavras a conhecer

Termo	Numa linha
Decisão arquitetural	Uma decisão difícil de reverter, com muita coisa a depender dela
Teste de Reversibilidade	Quão difícil é reverter isto, e quanto vai depender disto?
Gravidade	As dependências que se acumulam à volta de uma decisão ao longo do tempo
Raio de impacto	Tudo o mais que se move quando uma decisão muda
Registo 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 de que abdica para o conseguir
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, registo a registo
Descontinuar	Marcar algo como de saída e depois retirá-lo de forma deliberada, em vez de o alterar no próprio lugar
Utilizador de grande volume	Um utilizador de comunidade (Customer Community entre as licenças) sem função, fora do modelo de partilha
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 ao estilo do curso. Decida a sua resposta antes de abrir.

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

Pergunte porquê, e quantas aprovações pode haver. Se puder haver mais de duas ou três, o requisito é registar cada aprovação, não acrescentar campos: um objeto filho, um registo 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 chumba 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 guarde um número. Qual é a sua abordagem?

Não o altere no próprio lugar. Descubra o que depende dele (Flows, Apex, relatórios, integrações, agentes) e o que acontece aos 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 marcações por local por dia, cerca de 305 dias por ano, dois registos por marcação, cinco anos guardados, 30% de crescimento. Aproximadamente quantos registos, e porque é que isso importa?

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

5. Uma carga noturna informa «concluído» para um milhão de registos. Como sabe que funcionou?

Reconcilia. O lado que recebe confirma cada registo que guardou; o remetente compara o que enviou com o que foi confirmado. Confirmações em falta significam que não funcionou, diga o que disser o estado do job, e mostram que registos tentar de novo, encaminhar para uma pessoa ou alertar. Releia Um sucesso parcial continua a ser uma falha que precisa de entender.

6. Uma comunidade de 15 milhões de utilizadores Customer Community precisa de acesso complexo a registos. Alguém propõe partilha Apex. Qual é o problema?

São utilizadores de grande volume: sem funções, fora do modelo de partilha, por isso não há registo de partilha para o Apex gravar. O acesso vem de conjuntos de partilha e grupos de partilha. A licença decidiu que ferramentas de partilha existem. Releia Um exemplo prático: partilha Apex.

7. Uma ferramenta de IA gera vinte objetos para uma nova aplicação em minutos. Qual é agora o trabalho do arquiteto?

Decidir se deveríamos ter cinco. Entender o modelo suficientemente bem para o defender: porquê estes objetos e relações, onde estão as chaves e os dados mestres, o que acontece à escala. Verificar os factos 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 os seus pesos. Confira sempre a versão atual antes de marcar o exame.