Steve Trucking, o que eu arquitetaria

🌐 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

Módulo 6 de 6 do capítulo Dados mestres e identidade, capítulo 6 do curso Data Architect, e o fim da Parte 1. Anterior: Quando a autoridade é partilhada · Próximo: a Parte 2 começa com Designing for Scale (coming soon)

A pergunta que este checkpoint responde: Consegue juntar a Parte 1 num cenário real?

Tente primeiro o desafio. Esta é a minha resolução comentada do desafio do Checkpoint 1. Se ainda não desenhou o seu próprio design, faça-o antes de continuar a ler. O valor está em comparar o seu raciocínio com o meu, não em ler a resposta.

Isto é «O que eu arquitetaria»: uma solução viável possível, não a resposta, com os trade-offs nomeados e as minhas posições tomadas. Ainda não tratámos de grandes volumes de dados, design de consultas, padrões de integração, migração nem transações, e isso é de propósito: a arquitetura desenvolve-se à medida que aprende mais. Mas a Parte 1 dá-nos o suficiente para montar o esqueleto.

Comece pelos números

Do briefing: cerca de 3.300 entregas por dia útil, um milhão por ano, a crescer 30% ao ano. Cerca de 1,6 itens de linha por entrega (1,6 milhões por ano); umas oito mudanças de estado por entrega (8 milhões por ano); quatro a cinco milhões de fotografias por ano; cerca de 200 mil leituras de GPS por dia; cerca de 180 mil casos por ano; três Parceiros retalhistas a enviar manifestos de três formas diferentes; nove centros de distribuição; 330 camiões com equipas de duas pessoas. E a Steve Trucking já corre uma org Salesforce com Service Cloud, Field Service e um portal de parceiros. Conte os zeros antes de desenhar uma única caixa. Vão decidir várias coisas a seguir.

O núcleo das entregas: olhe para a nave-mãe

As entregas são o coração disto, e o Field Service já faz a expedição. Por isso começo pelo modelo padrão do Field Service, como fez o recorte do capítulo 3:

Conceito de negócio	Objeto Salesforce	Porquê
Parceiro retalhista	Account (tipo de registo Retail Partner)	Uma empresa com a qual a Steve Trucking tem contrato; carrega contratos, casos e acesso ao portal
Pessoal do parceiro (gestores de CD, pessoal das lojas)	Contact	Os utilizadores do portal têm de ser Contactos
Uma entrega: um Destinatário, uma morada, uma encomenda do parceiro, um dia	Work Order	A unidade de trabalho do Field Service; o agendamento, a aplicação móvel e os relatórios de serviço dependem dela
Cada artigo ou serviço: o frigorífico, a instalação, a recolha	Work Order Line Item	Divide o trabalho, orienta as checklists e a faturação
O tipo de paragem: só entrega, com instalação, com recolha	Work Type	Define a duração, as competências e a checklist de instalação
A visita agendada e a sua janela	Service Appointment	O que o Field Service agenda e a aplicação da equipa mostra
Equipas e camiões; áreas de expedição dos CD	Service Resource, Service Crew, Service Territory	O Field Service agenda uma equipa como um único recurso
Dúvidas dos Destinatários, reclamações dos parceiros	Case	A consola de atendimento, direitos (entitlements), e-mail para caso
A lista do parceiro para terça-feira no CD de Phoenix	Manifest__c (personalizado)	Nada padrão representa a unidade de receção, reconciliação e reprocessamento

Todo o resto continua padrão. Resistir a mais objetos personalizados é deliberado: a pergunta do capítulo 1 era quando deve um arquiteto resistir a mais um, e aqui a resposta é «quase sempre». A linha de encomenda do parceiro, por exemplo, não é um objeto novo. É a Ordem de trabalho, identificada pela referência do parceiro.

Click to enlarge

Cresce a partir do final do capítulo 3 (Projete o modelo físico Salesforce): os mesmos objetos nos mesmos lugares, com a equipa, a área de expedição, o caso e o que o Checkpoint 1 mantém fora do núcleo acrescentados.

A chave que faz corresponder a encomenda de um parceiro a uma entrega

Cada linha do manifesto torna-se uma Ordem de trabalho, ligada ao seu Manifesto. A chave é a pergunta a que mais quero resposta: como sabemos que esta linha do parceiro é aquela entrega? A minha resposta: um ID externo na Ordem de trabalho construído a partir do Parceiro retalhista e da própria referência de encomenda e de entrega do parceiro (algo como KEYSTONE-PHX-8843119-1), marcado como único. Um campo por fonte, um-para-um. É o identificador do parceiro, não o nosso: o «vários identificadores para uma coisa» do capítulo 2, e o «o parceiro é dono da sua referência de encomenda» do módulo 1.

Porque importa: os manifestos chegam com um a dois dias de antecedência e são revistos no próprio dia. Com esta chave, cada manifesto reenviado ou revisto faz upsert em vez de criar duplicados. A revisão atualiza a Ordem de trabalho, um campo regista-a, e uma mudança numa entrega já com rota alerta o coordenador: a mudança do parceiro é aplicada, mas assinalada até a expedição a confirmar. É também isto que muda em relação ao desenho do capítulo 4. Hoje cada manifesto cai no RouteDesk, e os coordenadores voltam a escrever as rotas no Salesforce e as paragens concluídas de volta. Neste design, os manifestos entram diretamente no Salesforce, com upsert pela chave do parceiro; o RouteDesk é desativado, e acaba a reintrodução manual. O capítulo de integração projeta os três formatos de entrada. A decisão de dados é a chave.

O Destinatário: conta pessoal, Contacto ou nenhum dos dois?

Esta é a decisão de dados mais interessante da Parte 1, então aqui estão as opções, e depois a minha escolha.

Opção A: contas pessoais. Cada Destinatário torna-se uma conta pessoal, ligada a cada entrega. A favor: padrão, funciona naturalmente com o Service Cloud, as mensagens e a consola, reconhece Destinatários recorrentes. Contra: cerca de um milhão de novos Destinatários por ano, cada um uma conta pessoal com cerca do dobro do armazenamento de uma conta empresarial (Estimated Record Size by Object Type (opens in a new tab), em inglês), por isso, em dois anos, um dos maiores objetos da org. E os Destinatários não são clientes da Steve Trucking. São clientes de cada Parceiro retalhista, e a Steve Trucking nunca pode misturar o cliente de um parceiro com o de outro (S2).

Opção B: Contactos sob a conta do Parceiro retalhista. Contra: um milhão de Contactos sob três ou quatro contas é desequilíbrio pai-filho a uma escala gigantesca, muito além da orientação da Salesforce de cerca de 10 mil filhos por pai (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab), em inglês). Esta é a opção para mostrar, e rejeitar.

Opção C: o Destinatário vive na entrega. O nome, o telefone, o e-mail, a morada e as notas de entrega do Destinatário são campos na Ordem de trabalho (os campos de morada já são padrão ali), capturados do manifesto. A favor: nenhum objeto grande novo; os dados vivem exatamente enquanto a entrega precisa deles; a eliminação acontece por entrega, no prazo do parceiro; e o isolamento entre parceiros vem de graça, porque cada entrega pertence a um parceiro. Contra: um Destinatário recorrente não é reconhecido como a mesma pessoa.

Esse é o equilíbrio a encontrar. Alguma vez vai ser preciso reconhecer várias entregas como sendo da mesma pessoa, no mesmo lugar? Dar um login a essa pessoa? Essa é a linha entre um Destinatário que precisa de um registo próprio e os dados do Destinatário que são simplesmente dados sobre a entrega. E existe um caminho do meio. Leve o próprio ID de cliente do Parceiro retalhista como um campo na entrega, um Retail Partner Customer ID (ID de cliente do Parceiro retalhista). Não cria um registo de Destinatário, mas liga entre si as entregas que um parceiro envia para o mesmo cliente, o que é o início de uma experiência do cliente mais unificada, e leva diretamente de volta ao sistema do Parceiro retalhista, onde esse cliente realmente vive. É o identificador deles, por isso só significa algo em conjunto com o parceiro: o cliente 4417 de um parceiro não tem nada a ver com o de outro.

Na minha opinião profissional, a Opção C é a escolha certa. A parte do não reconhecimento é aceitável, até desejável: a Steve Trucking não tem relação com estas pessoas para além da entrega. É outra vez o módulo 1: o Destinatário é cliente do parceiro, e o parceiro é a autoridade sobre quem ele é. E é o capítulo 5: dados pessoais que ficam num só lugar, ligados a uma entrega, são muito mais fáceis de proteger, reter e eliminar. E resiste às formas normais do capítulo 2: os dados do Destinatário são um para um com a entrega, por isso pertencem-lhe. Um filho Destinatário separado pouparia alguns valores repetidos à custa de mais um objeto, mais uma relação e a respetiva sobrecarga, e a única forma de poupar mais seria tratar a mesma pessoa como uma só entre Parceiros retalhistas, o que não vamos fazer. Por isso a entrega transporta o Destinatário, com o Retail Partner Customer ID como o caminho de volta ao próprio sistema do parceiro.

Click to enlarge

Eu unificaria os Destinatários entre parceiros?

João Silva, Rua Principal, 123, aparece no manifesto da Redrock e no da Brightwave. Provavelmente a mesma pessoa. A Steve Trucking deve unificá-los? Não, de propósito. Unificar Destinatários entre Parceiros retalhistas violaria o S2: um parceiro nunca pode ver os Destinatários de outro, e uma identidade unificada é exatamente a ponte por onde isso escaparia. É a posição deste capítulo aplicada: faça correspondências a menos onde misturar custa caro, e aqui misturar custa muito caro.

Se mais tarde um Parceiro retalhista quiser o reconhecimento de Destinatários recorrentes dentro das suas próprias entregas, esse é um trabalho para uma ferramenta de resolução de identidade, como a do Data 360, limitada a esse parceiro: um mapa ao estilo registry, não uma conta pessoal, e nunca entre parceiros. Um mapa de quem é quem não concede propriedade, e não concede acesso.

O que fica na org, e o que não fica

O capítulo 3 perguntou onde os dados devem viver. Aqui os zeros respondem:

• O estado atual vive na Marcação de serviço e na Ordem de trabalho. O histórico das mudanças de estado, cerca de 8 milhões por ano e a crescer, não precisa de viver na org do núcleo. Cada mudança é publicada como um evento e guardada no data warehouse, o Snowflake. A org guarda o estado atual; o histórico continua lá para atendimento, operações e análise, só que não na base de dados operacional.
• As fotografias (quatro a cinco milhões por ano, algumas a mostrar pessoas ou o interior de uma casa) vivem fora do núcleo, num armazenamento feito para esse volume, enviadas diretamente da aplicação da equipa. A org guarda só o que precisa: um pequeno registo de índice por fotografia, ou só uma contagem e um indicador de «fotografias obrigatórias da instalação completas». A minha preferência é a opção mais leve: manter a org enxuta, e deixar o repositório de fotografias ser dono do seu índice e da sua retenção.
• As leituras de GPS (200 mil por dia) ficam no FleetLink e vão para o Snowflake; a org só precisa da última posição para a página de seguimento e o mapa do expedidor.
• Os oito anos de histórico do RouteDesk (cerca de 5 milhões de entregas) vão para o data warehouse ou um arquivo, acessíveis para reclamações. O que entra na org, se alguma coisa entrar, é uma decisão de migração para a Parte 2.

Click to enlarge

Checkpoint 1: o que eu arquitetaria. Os mesmos lugares do panorama do capítulo 4 (O panorama da Steve Trucking), sem a reintrodução manual e sem a folha de cálculo.

Quem vê o quê, e quem precisa de licença

• Os Parceiros retalhistas veem só as suas próprias entregas (S2). Cada Ordem de trabalho carrega o seu Parceiro retalhista; os utilizadores do portal veem as entregas do seu parceiro, e os gestores de CD só as do seu CD.
• Os utilizadores parceiros precisam de uma licença de portal que suporte regras de partilha e funções: Customer Community Plus ou Partner Community. Os lugares no estádio do capítulo 3: os lugares mais baratos não recebem a partilha de que este design precisa. As duas licenças precisam de funções para os utilizadores externos, e a Salesforce avisa que mais funções tornam a org mais lenta (Experience Cloud User Licenses (opens in a new tab), em inglês). Uma função por parceiro e por CD não faz mal; uma função para cada loja, não.

Conhecimento para o exame. Saiba que licenças externas trazem partilha padrão: Customer Community Plus e Partner Community (com funções para os utilizadores externos), não a Customer Community, que usa conjuntos de partilha.

• Os Destinatários não precisam de licença. A página de seguimento mostra uma entrega através de um link com um token que expira (S3), não de um login.
• Cuidado com o desequilíbrio. Centenas de milhares de Ordens de trabalho por ano a apontar para três ou quatro contas de parceiros é desequilíbrio de dados na conta. Uma opção é uma conta filha por CD sob cada parceiro, o que espalha os filhos por nove ou mais pais; arquivar as entregas concluídas depois do prazo de reclamações mantém baixo o número de filhos ativos por pai. A Parte 2 enfrenta isto.

O que eu não faria

Não criaria uma conta pessoal para cada Destinatário só porque um Destinatário é um indivíduo. Não penduraria um milhão de Contactos em três contas. Não construiria um objeto Entrega personalizado ao lado da Ordem de trabalho do Field Service. Não unificaria Destinatários entre parceiros. Não poria milhões de fotografias ou leituras de GPS no armazenamento do núcleo. E não chamaria golden record a um Destinatário unificado a menos que tivéssemos de facto tomado uma decisão de dados mestres.

O que ainda está em aberto

A Parte 1 montou o esqueleto; a Parte 2 põe-no à prova. A fasquia de grandes volumes de dados no terceiro ano (Ordens de trabalho, Marcações de serviço e itens de linha estão todos em território de grande volume dentro de dois ou três anos), o design de consultas para vistas de lista limitadas por parceiro, as três integrações de entrada e os três feeds de estado, a migração do RouteDesk, as transações no próprio dia, e o design de segurança por trás do portal. A Steve Trucking também vai mudar. Guarde este design; vai voltar a ele.

O que um arquiteto decide aqui

• Quais objetos padrão carregam o núcleo (aqui, os do Field Service), e quais objetos personalizados são realmente justificados (aqui, um).
• A chave que faz corresponder a linha de encomenda de cada parceiro a uma entrega, e porque é que pertence ao parceiro.
• O que é o Destinatário, com base na relação que a Steve Trucking realmente tem com ele.
• Se identidades devem ser unificadas, e onde misturar é caro demais para arriscar.
• O que fica na org, o que vive fora do núcleo, e de que licenças depende o design.

Para saber mais

• O briefing e os desafios da Steve Trucking (em inglês) (D1, D3, DC1).
• Salesforce Help, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Considerations for Object Relationships (opens in a new tab) e Experience Cloud User Licenses (opens in a new tab) (em inglês), consultados em 2026-10-14.
• Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (em inglês), como citado no capítulo 3.