Hoppa till innehåll
SteveTechArcSteveTechArc Courses

Tänk som en dataarkitekt

Finns även på 28 språk

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

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp.
Bilden är skapad med AI

Studieguide för kapitel 1 i kursen Data Architect. Läs de sju modulerna först; den här sidan hjälper dig att kontrollera vad som har fastnat.

Om den här studieguiden. Den bygger enbart på kursens eget innehåll och på listan över mål i provguiden som Salesforce publicerar. Den bygger aldrig på verkliga provfrågor, och den gör inga anspråk på att veta vad som kommer på provet. Om du har skrivit provet: skicka inte frågor från det till mig. Certifieringsavtalet förbjuder att de delas, och att memorera svar är ändå fel sätt att bli arkitekt.

Det här kapitlet innehåller färre provfakta, och det är med avsikt. Det handlar om hur en arkitekt tänker, och inget provmål hör enbart till det. Men provet är byggt av scenarier: en verksamhet, några siffror, en begränsning och flera svar som skulle kunna fungera. Vanorna i det här kapitlet är hur du läser de scenarierna. Därför anger checklistan nedan vilket mål varje punkt stöder, i stället för att påstå att den testas direkt.

Inför provet

Section titled “Inför provet ”

Bocka av dem allteftersom. Var och en länkar till där den lärs ut.

Att läsa ett scenario som en arkitekt (stöder alla mål)

  • Jag skiljer det verkliga kravet från designen det kom förklätt i (”vi behöver fälten Godkännare 2 och Godkännare 3” jämfört med ”vi behöver följa varje godkännande”). (Ta inte bara emot kravet)
  • Jag letar efter de underförstådda kraven som ingen har uttalat: ägarskap, aktualitet, fel, lagringstid, åtkomst. (Leta efter de underförstådda kraven)
  • Jag sätter siffror på det: volym per dag, per år, med tillväxt, och jag märker när en nolla till ändrar svaret. (Känn dina siffror)
  • Bland flera svar som fungerar jämför jag vad vart och ett vinner och ger upp mot de angivna kraven och begränsningarna. (Vet vad du ger upp, Begränsningar ändrar svaret)
  • Jag behandlar kostnad, licenser och gränser som en del av om ett verktyg passar, inte som en eftertanke. (De nio frågorna)

Datamodellen (stöder DM-1)

Att ändra det som redan finns (stöder DM-1 och SDM-2)

  • Jag vet varför det kan ställa till problem senare att ändra ett fälts typ, eller att göra ett befintligt fält Required (obligatoriskt), och varför plattformen blockerar en typändring så länge kod eller flows refererar till fältet. (Var försiktig med att ändra skelettet)
  • Jag känner till mönstret lägg till hellre än ändra, fasa ut hellre än överraska, och att Field Usage kan markera ett fält som kandidat för utfasning. (Var försiktig med att ändra skelettet)
  • Jag känner till fakta om master-detail bakom reversibilitetstestet: detaljpostens åtkomst och ägarskap följer huvudposten, om huvudposten raderas raderas dess detaljposter, sammanställningsfält kräver master-detail, och en lookup-relation kan konverteras till master-detail bara när varje post har ett värde. (Reversibilitetstestet, Utforska vidare)

Licenser och delning (stöder SDM-1)

  • Jag vet att community-användare med hög volym (bland dem Customer Community) inte har några roller och inte använder delningsmodellen, så åtkomsten kommer från sharing sets och share groups, och Apex-delning kan inte nå dem. (Ett genomarbetat exempel: Apex-delning)

Fel (stöder MIG-1 och integrationskapitlen)

Bortom provet

Section titled “Bortom provet ”

Provet är golvet, inte taket. Det här är vanorna från kapitlet som en arkitekt behöver, oavsett om någon fråga någonsin handlar om dem.

  • Någon måste hålla i ritningen. Arkitektur är att fatta bra beslut med ofullständig information, och att känna till deras konsekvenser.
  • Datamodellen är skelettet. Allt annat byggs på den.
  • Reversibilitetstestet: hur svårt är det här att backa, och hur mycket kommer att bero på det?
  • Arkitektur skapar gravitation. Det är beroendena som gör förändring dyr, inte förändringen i sig.
  • Tänk på sprängradien, inne i Salesforce och över hela företaget. Arkitektur är trafik i båda riktningarna.
  • Skriv ner varför: sammanhang, alternativ, beslut, konsekvenser, ägare, översyn. Ersätt; radera inte.
  • Bäst på vad? Ett suboptimalt beslut kan vara en del av en optimal arkitektur, om du vet att du fattar det.
  • Bär med dig en bild av det optimala, så att du vet åt vilket håll du rör dig bort från det, och varför.
  • Think Correct. Think Fast. Snabbheten kommer av tänkande som gjorts före ögonblicket.
  • Bygg för i dag. Planera för i morgon. Planera för fel. Och använd 30 % tillväxt när ingen ger dig en siffra.
  • Lär dig de nio frågorna, inte bara svaren.
  • AI är en raketbooster. Att generera är inte att bedöma, oåterkalleligt är fortfarande oåterkalleligt, och mänsklig granskning är ingen ceremoni. Lita, men kontrollera.

Ord att kunna

Section titled “Ord att kunna ”
TermPå en rad
Arkitektoniskt beslutEtt beslut som är svårt att backa, med mycket som beror på det
ReversibilitetstestetHur svårt är det här att backa, och hur mycket kommer att bero på det?
GravitationBeroendena som samlas runt ett beslut över tid
Sprängradie (blast radius)Allt annat som rör sig när ett beslut ändras
BeslutsloggSammanhang, alternativ, beslut, konsekvenser, ägare och tidpunkt för översyn, kort och koncist
AvvägningVad ett alternativ vinner, och vad det ger upp för att få det
Underförstått kravNågot verksamheten förväntar sig utan att be om det, som återställning när en laddning misslyckas
Steves ”antal nollor” (Steve’s Number of Zeros)En nolla till i volymen kan ändra hela arkitekturen
AvstämningAtt jämföra vad som borde ha hänt med vad som faktiskt hände, post för post
Fasa utMarkera något som på väg bort och pensionera det sedan medvetet, i stället för att ändra det på plats
Användare med hög volymEn community-användare (Customer Community är en av licenserna) utan roll, utanför delningsmodellen
SchemaspridningObjekt och fält som hopar sig för att de var billiga att skapa, tills ingen har designat modellen

Testa dig själv

Section titled “Testa dig själv ”

Korta scenarier i kursens stil. Bestäm ditt svar innan du öppnar det.

1. Ett säljteam ber om fälten Godkännare 2 och Godkännare 3, vart och ett med ett datum, på affärsmöjligheten (Opportunity). Vad frågar du, och vad skulle du kunna bygga?

Fråga varför, och hur många godkännanden det kan bli. Om det kan bli fler än två eller tre är kravet att följa varje godkännande, inte att lägga till fält: ett underordnat objekt, en post per godkännande. Läs Ta inte bara emot kravet igen.

2. Någon vill byta etikett på ett fält, och någon annan vill ändra formatet på kundidentifieraren som fem system redan lagrar. Vilket förtjänar mer av din uppmärksamhet, och varför?

Identifieraren. Etiketten är billig att ändra. Identifieraren klarar inte reversibilitetstestet: svår att backa, och mycket beror redan på den. Lägg uppmärksamhet i proportion till vad det kostar att ha fel. Läs En del beslut är billiga att ändra igen.

3. Ett textfält har använts i flera år. Nu vill verksamheten att det ska innehålla ett tal. Hur gör du?

Ändra det inte på plats. Ta reda på vad som beror på det (Flows, Apex, rapporter, integrationer, agenter) och vad som händer med de gamla data. Oftast: lägg till ett nytt fält, migrera medvetet och fasa ut det gamla. Läs Var försiktig med att ändra skelettet igen.

4. 1 200 platser, 100 besök per plats och dag, ungefär 305 dagar om året, två poster per besök, fem år sparade, 30 % tillväxt. Ungefär hur många poster blir det, och varför spelar det roll?

Ungefär 73 miljoner poster det första året (36,6 miljoner besök, två poster vardera), och över 650 miljoner på fem år med tillväxt. Samma funktion, ett par nollor till, en helt annan arkitektur. Läs Känn dina siffror igen.

5. En nattlig laddning rapporterar ”slutförd” för en miljon poster. Hur vet du att den fungerade?

Du stämmer av. Den mottagande sidan bekräftar varje post den sparade; avsändaren jämför det den skickade med det som bekräftades. Saknade bekräftelser betyder att den inte fungerade, vad jobbstatusen än säger, och talar om vilka poster du ska försöka igen, skicka till en person eller larma om. Läs Delvis lyckat är fortfarande ett fel som du behöver förstå igen.

6. En community med 15 miljoner Customer Community-användare behöver komplex åtkomst till poster. Någon föreslår Apex-delning. Vad är problemet?

De är användare med hög volym: inga roller, utanför delningsmodellen, så det finns ingen delningspost för Apex att skriva. Åtkomsten kommer från sharing sets och share groups. Licensen avgjorde vilka delningsverktyg som finns. Läs Ett genomarbetat exempel: Apex-delning igen.

7. Ett AI-verktyg genererar tjugo objekt för en ny app på några minuter. Vad är arkitektens jobb nu?

Avgöra om vi borde ha fem. Förstå modellen tillräckligt väl för att försvara den: varför de här objekten och relationerna, var nycklarna och masterdata finns, vad som händer i stor skala. Kontrollera de fakta den byggde på. Att generera är inte att bedöma. Läs Billig implementation flyttar värdet igen.

Utforska vidare

Section titled “Utforska vidare ”