Pensare da Data Architect
Disponibile anche in 28 lingue
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · 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)
Guida allo studio del capitolo 1 del corso Data Architect. Leggi prima i sette moduli; questa pagina ti aiuta a verificare cosa ti è rimasto.
Su questa guida allo studio. È costruita solo con i contenuti di questo corso e con l’elenco degli obiettivi della guida all’esame pubblicata da Salesforce. Non si basa mai su domande reali d’esame, e non pretende di sapere cosa c’è nell’esame. Se hai sostenuto l’esame, per favore non mandarmi domande: l’accordo di certificazione vieta di condividerle, e memorizzare le risposte è comunque il modo sbagliato per diventare architetto.
Questo capitolo contiene pochi fatti d’esame, ed è voluto. Parla di come pensa un architetto, e nessun obiettivo d’esame gli appartiene in esclusiva. Ma l’esame è costruito su scenari: un business, qualche numero, un vincolo e diverse risposte che potrebbero funzionare. Le abitudini di questo capitolo sono il modo in cui leggi quegli scenari. Per questo la checklist qui sotto indica quale obiettivo sostiene ciascun punto, invece di affermare che sia verificato direttamente.
Per l’esame
Sezione intitolata “Per l’esame ”Spuntali man mano. Ognuno rimanda al punto in cui è spiegato.
Leggere uno scenario da architetto (sostiene tutti gli obiettivi)
- Separo il vero requisito dalla soluzione in cui è arrivato (“ci servono i campi Approvatore 2 e Approvatore 3” rispetto a “dobbiamo tracciare ogni approvazione”). (Non limitarti a prendere il requisito)
- Cerco i requisiti impliciti che nessuno ha espresso: responsabilità, aggiornamento, guasti, conservazione, accesso. (Cerca i requisiti impliciti)
- Ci metto i numeri: volume al giorno, all’anno, con la crescita, e mi accorgo quando uno zero in più cambia la risposta. (Conosci i tuoi numeri)
- Tra diverse risposte che funzionano, confronto cosa guadagna e a cosa rinuncia ciascuna rispetto ai requisiti e ai vincoli dichiarati. (Sappi a cosa stai rinunciando, I vincoli cambiano la risposta)
- Considero costi, licenze e limiti parte del giudizio sull’adeguatezza di uno strumento, non un ripensamento. (Le nove domande)
Il modello dati (sostiene DM-1)
- So giudicare un modello in base a se sostiene il business, può crescere con esso e rende. (Sostenere. Crescere. Rendere.)
- So riconoscere un modello troppo piatto (Campo 1, Campo 2, Campo 3), troppo normalizzato o costruito sull’oggetto standard sbagliato. (Troppo piatto, troppo complicato o semplicemente sbagliato)
- So perché un elenco di selezione va bene per un elenco breve e stabile e una relazione di ricerca per un elenco che continua a crescere o arriva da un’integrazione. (Molti modi per risolvere il problema)
- So che una chiave che porta un significato (per esempio una parte di un nome) si rompe quando quel significato cambia. (Alcune decisioni costano poco da cambiare)
Cambiare ciò che esiste già (sostiene DM-1 e SDM-2)
- So perché cambiare il tipo di un campo, o rendere Obbligatorio un campo esistente, può rompere le cose più avanti, e perché la piattaforma blocca un cambio di tipo finché codice o flow fanno riferimento al campo. (Attenzione a cambiare lo scheletro)
- Conosco il pattern aggiungi invece di modificare, depreca invece di sorprendere, e so che Field Usage può segnare un campo come candidato alla deprecazione. (Attenzione a cambiare lo scheletro)
- Conosco i fatti sulla relazione master-dettaglio dietro il Test di Reversibilità: l’accesso e la titolarità del dettaglio seguono il master, eliminare un master ne elimina i dettagli, i campi di riepilogo roll-up richiedono una master-dettaglio, e una relazione di ricerca si converte in master-dettaglio solo quando ogni record ha un valore. (Il Test di Reversibilità, Per approfondire)
Licenze e condivisione (sostiene SDM-1)
- So che gli utenti ad alto volume di una community (tra cui Customer Community) non hanno ruoli e non usano il modello di condivisione, quindi l’accesso viene dai set di condivisione e dai gruppi di condivisione, e la condivisione Apex non può raggiungerli. (Un esempio svolto: la condivisione Apex)
Il guasto (sostiene MIG-1 e i capitoli sull’integrazione)
- So che “job completato” non è la stessa cosa di i dati sono corretti, e come la riconciliazione trova i record che non sono arrivati. (Anche un successo parziale è un guasto che devi capire)
Oltre l’esame
Sezione intitolata “Oltre l’esame ”L’esame è il pavimento, non il soffitto. Queste sono le abitudini di questo capitolo di cui un architetto ha bisogno, che una domanda le chieda o no.
- Qualcuno deve tenere il progetto. L’architettura è prendere buone decisioni con informazioni incomplete, e conoscerne le conseguenze.
- Il modello dati è lo scheletro. Tutto il resto è costruito sopra.
- Il Test di Reversibilità: quanto è difficile tornare indietro, e quanto ne dipenderà?
- L’architettura crea gravità. Sono le dipendenze a rendere costoso il cambiamento, non il cambiamento in sé.
- Pensa al raggio d’impatto, dentro Salesforce e in tutta l’azienda. L’architettura è un traffico a doppio senso.
- Scrivi il perché: contesto, opzioni, decisione, conseguenze, responsabile, revisione. Sostituisci; non cancellare.
- Migliore in cosa? Una decisione subottimale può far parte di un’architettura ottimale, se sai di prenderla.
- Porta con te un’immagine dell’ottimale, così sai in quale direzione te ne stai allontanando, e perché.
- Think Correct. Think Fast. La velocità viene dal ragionamento fatto prima del momento.
- Costruisci per oggi. Pianifica per domani. Pianifica per il guasto. E usa una crescita del 30 per cento quando nessuno ti dà un numero.
- Impara le nove domande, non solo le risposte.
- L’IA è un razzo propulsore. Generare non è giudicare, ciò che è irreversibile resta irreversibile, e la revisione umana non è una cerimonia. Fidati, ma verifica.
Parole da conoscere
Sezione intitolata “Parole da conoscere ”| Termine | In una riga |
|---|---|
| Decisione architetturale | Una decisione difficile da invertire, da cui dipende molto |
| Test di Reversibilità | Quanto è difficile tornare indietro, e quanto ne dipenderà? |
| Gravità | Le dipendenze che si raccolgono nel tempo intorno a una decisione |
| Raggio d’impatto | Tutto ciò che si muove quando una decisione cambia |
| Registro delle decisioni | Contesto, opzioni, decisione, conseguenze, responsabile e momento di revisione, in poco spazio |
| Trade-off | Cosa guadagna un’opzione, e a cosa rinuncia per ottenerlo |
| Requisito implicito | Qualcosa che il business si aspetta senza chiederlo, come il ripristino quando un caricamento fallisce |
| Il Numero di Zeri di Steve | Uno zero in più nel volume può cambiare l’intera architettura |
| Riconciliazione | Confrontare ciò che sarebbe dovuto succedere con ciò che è successo, record per record |
| Deprecare | Segnare qualcosa come in via di dismissione, poi ritirarlo in modo deliberato, invece di cambiarlo sul posto |
| Utente ad alto volume | Un utente di community (tra le licenze, Customer Community) senza ruolo, fuori dal modello di condivisione |
| Proliferazione dello schema | Oggetti e campi che si accumulano perché costava poco crearli, finché nessuno ha più progettato il modello |
Mettiti alla prova
Sezione intitolata “Mettiti alla prova ”Brevi scenari nello stile del corso. Decidi la tua risposta prima di aprirla.
1. Un team di vendita chiede i campi Approvatore 2 e Approvatore 3, ciascuno con una data, sull'Opportunità. Cosa chiedi, e cosa potresti costruire?
Chiedi perché, e quante approvazioni possono esserci. Se possono essere più di due o tre, il requisito è tracciare ogni approvazione, non aggiungere campi: un oggetto figlio, un record per ogni approvazione. Rileggi Non limitarti a prendere il requisito.
2. Qualcuno vuole rinominare l'etichetta di un campo, e qualcun altro vuole cambiare il formato dell'identificatore cliente che cinque sistemi memorizzano già. Quale merita più attenzione, e perché?
L’identificatore. L’etichetta costa poco da cambiare. L’identificatore non supera il Test di Reversibilità: è difficile tornare indietro, e molto ne dipende già. Investi attenzione in proporzione al costo dell’errore. Rileggi Alcune decisioni costano poco da cambiare.
3. Un campo di testo è in uso da anni. Ora il business vuole che contenga un numero. Come lo affronti?
Non modificarlo sul posto. Trova cosa ne dipende (Flow, Apex, report, integrazioni, agenti) e cosa succede ai dati vecchi. Di solito: aggiungi un nuovo campo, migra in modo deliberato e depreca quello vecchio. Rileggi Attenzione a cambiare lo scheletro.
4. 1.200 sedi, 100 appuntamenti al giorno per sede, circa 305 giorni all'anno, due record per appuntamento, cinque anni conservati, crescita del 30 per cento. Circa quanti record, e perché conta?
Circa 73 milioni di record nel primo anno (36,6 milioni di appuntamenti, due record ciascuno), e oltre 650 milioni in cinque anni con la crescita. Stessa funzionalità, un paio di zeri in più, un’architettura molto diversa. Rileggi Conosci i tuoi numeri.
5. Un caricamento notturno segnala “completato” su un milione di record. Come sai che ha funzionato?
Riconcili. Il lato che riceve conferma ogni record che ha salvato; chi invia confronta ciò che ha inviato con ciò che è stato confermato. Le conferme mancanti significano che non ha funzionato, qualunque cosa dica lo stato del job, e ti dicono quali record riprovare, passare a una persona o segnalare con un avviso. Rileggi Anche un successo parziale è un guasto che devi capire.
6. Una community di 15 milioni di utenti Customer Community ha bisogno di un accesso ai record complesso. Qualcuno propone la condivisione Apex. Qual è il problema?
Sono utenti ad alto volume: niente ruoli, fuori dal modello di condivisione, quindi non c’è alcun record di condivisione che Apex possa scrivere. L’accesso viene dai set di condivisione e dai gruppi di condivisione. È stata la licenza a decidere quali strumenti di condivisione esistono. Rileggi Un esempio svolto: la condivisione Apex.
7. Uno strumento di IA genera in pochi minuti venti oggetti per una nuova app. Qual è ora il compito dell'architetto?
Decidere se dovremmo averne cinque. Capire il modello abbastanza da difenderlo: perché questi oggetti e relazioni, dove sono le chiavi e i dati master, cosa succede su larga scala. Verificare i fatti su cui si è basato. Generare non è giudicare. Rileggi Un’implementazione a basso costo sposta il valore.
Per approfondire
Sezione intitolata “Per approfondire ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Guida di Salesforce (in inglese, consultato il 2026-09-25): l’elenco ufficiale degli obiettivi e dei loro pesi. Controlla sempre la versione attuale prima di prenotare l’esame.