Ga naar inhoud
SteveTechArcSteveTechArc Courses

Denken als een data-architect

Ook beschikbaar in 28 talen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · 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.
Afbeelding gegenereerd met AI

Studiegids bij hoofdstuk 1 van de cursus Data Architect. Lees eerst de zeven modules; deze pagina helpt je na te gaan wat is blijven hangen.

Over deze studiegids. Hij is alleen gebaseerd op de eigen inhoud van deze cursus en op de lijst met doelstellingen in de gepubliceerde examengids van Salesforce. Hij is nooit gebaseerd op echte examenvragen, en hij beweert niet te weten wat er in het examen staat. Als je het examen hebt gedaan, stuur me dan alsjeblieft geen vragen eruit: de certificeringsovereenkomst verbiedt het delen ervan, en antwoorden uit je hoofd leren is sowieso de verkeerde manier om architect te worden.

Dit hoofdstuk bevat bewust weinig examenfeiten. Het gaat over hoe een architect denkt, en geen enkele examendoelstelling hoort er alleen bij. Maar het examen is opgebouwd uit scenario’s: een bedrijf, wat getallen, een beperking en meerdere antwoorden die zouden kunnen werken. De gewoonten in dit hoofdstuk zijn hoe je die scenario’s leest. Daarom zegt de checklist hieronder welke doelstelling elk punt ondersteunt, in plaats van te beweren dat het direct getoetst wordt.

Voor het examen

Section titled “Voor het examen ”

Vink ze af terwijl je verdergaat. Elk punt linkt naar de plek waar het behandeld wordt.

Een scenario lezen als een architect (ondersteunt elke doelstelling)

  • Ik scheid de echte eis van het ontwerp waarin hij binnenkwam (“we willen velden Goedkeurder 2 en Goedkeurder 3” tegenover “we moeten elke goedkeuring bijhouden”). (Neem de eis niet zomaar over)
  • Ik zoek de impliciete eisen die niemand uitsprak: eigenaarschap, actualiteit, falen, bewaartermijn, toegang. (Zoek de impliciete eisen)
  • Ik zet er getallen op: volume per dag, per jaar, met groei, en ik merk wanneer één nul meer het antwoord verandert. (Ken je getallen)
  • Tussen meerdere antwoorden die werken, vergelijk ik wat elk oplevert en inlevert tegenover de genoemde eisen en beperkingen. (Weet wat je inlevert, Beperkingen veranderen het antwoord)
  • Ik behandel kosten, licenties en limieten als onderdeel van de vraag of een gereedschap past, niet als bijzaak. (De negen vragen)

Het datamodel (ondersteunt DM-1)

Veranderen wat er al is (ondersteunt DM-1 en SDM-2)

  • Ik weet waarom het type van een veld veranderen, of een bestaand veld Verplicht maken, later dingen kan breken, en waarom het platform een typewijziging blokkeert zolang code of flows naar het veld verwijzen. (Wees voorzichtig met het veranderen van het skelet)
  • Ik ken het patroon voeg toe in plaats van te wijzigen, faseer uit in plaats van te verrassen, en weet dat Field Usage een veld kan markeren als kandidaat voor uitfasering. (Wees voorzichtig met het veranderen van het skelet)
  • Ik ken de feiten over master-detail achter de omkeerbaarheidstest: de toegang en het eigenaarschap van het detail volgen de master, het verwijderen van een master verwijdert zijn details, samenvattingsvelden vragen master-detail, en een lookup wordt alleen master-detail als elk record een waarde heeft. (De omkeerbaarheidstest, Verder lezen)

Licenties en sharing (ondersteunt SDM-1)

  • Ik weet dat high-volume communitygebruikers (onder meer Customer Community) geen rollen hebben en het sharingmodel niet gebruiken, dat hun toegang dus van sharing sets en share groups komt, en dat Apex sharing hen niet kan bereiken. (Een uitgewerkt voorbeeld: Apex sharing)

Falen (ondersteunt MIG-1 en de integratiehoofdstukken)

Voorbij het examen

Section titled “Voorbij het examen ”

Het examen is de vloer, niet het plafond. Dit zijn de gewoonten uit dit hoofdstuk die een architect nodig heeft, of er nu ooit een vraag over gesteld wordt of niet.

  • Iemand moet de bouwtekening vasthouden. Architectuur is goede beslissingen nemen met onvolledige informatie, en hun gevolgen kennen.
  • Het datamodel is het skelet. Al het andere wordt erop gebouwd.
  • De omkeerbaarheidstest: hoe moeilijk is dit terug te draaien, en hoeveel gaat ervan afhangen?
  • Architectuur creëert zwaartekracht. Afhankelijkheden maken verandering duur, niet de verandering zelf.
  • Denk aan de impactradius, binnen Salesforce en over de hele organisatie. Architectuur is verkeer in twee richtingen.
  • Schrijf op waarom: context, opties, beslissing, gevolgen, eigenaar, herziening. Vervang; wis niet.
  • De beste waarin? Een suboptimale beslissing kan deel zijn van een optimale architectuur, als je weet dat je haar neemt.
  • Heb een beeld van optimaal, zodat je weet in welke richting je ervan afwijkt, en waarom.
  • Think Correct. Think Fast. Snelheid komt van denkwerk dat vóór het moment is gedaan.
  • Bouw voor vandaag. Plan voor morgen. Plan voor falen. En gebruik 30 procent groei als niemand je een getal geeft.
  • Leer de negen vragen, niet alleen de antwoorden.
  • AI is een raketaanjager. Genereren is geen oordelen, onomkeerbaar is nog steeds onomkeerbaar, en menselijke review is geen ceremonie. Vertrouw, maar controleer.

Begrippen

Section titled “Begrippen ”
BegripIn één zin
ArchitectuurbeslissingEen beslissing die moeilijk terug te draaien is, met veel wat ervan afhangt
OmkeerbaarheidstestHoe moeilijk is dit terug te draaien, en hoeveel gaat ervan afhangen?
ZwaartekrachtDe afhankelijkheden die zich in de loop van de tijd rond een beslissing verzamelen
ImpactradiusAl het andere dat beweegt als een beslissing verandert
BeslisdocumentContext, opties, beslissing, gevolgen, eigenaar en herzieningsmoment, klein gehouden
AfwegingWat een optie oplevert, en wat ze daarvoor inlevert
Impliciete eisIets wat de business verwacht zonder erom te vragen, zoals herstel als een load faalt
Steve’s aantal nullenEén nul meer in het volume kan de hele architectuur veranderen
ReconciliatieVergelijken wat er had moeten gebeuren met wat er gebeurde, record voor record
UitfaserenIets markeren als op weg naar buiten en het dan bewust afschaffen, in plaats van het ter plekke te veranderen
High-volume userEen communitygebruiker (onder meer met de licentie Customer Community) zonder rol, buiten het sharingmodel
Wildgroei in het schemaObjecten en velden die zich opstapelen omdat ze goedkoop te maken waren, tot niemand het model meer ontworpen heeft

Test jezelf

Section titled “Test jezelf ”

Korte scenario’s in de stijl van de cursus. Bepaal je antwoord voordat je het openklapt.

1. Een salesteam vraagt om velden Goedkeurder 2 en Goedkeurder 3, elk met een datum, op de verkoopkans. Wat vraag je, en wat zou je kunnen bouwen?

Vraag waarom, en hoeveel goedkeuringen er kunnen zijn. Als het er meer dan twee of drie kunnen zijn, is de eis elke goedkeuring bijhouden, niet velden toevoegen: een child-object, één record per goedkeuring. Lees opnieuw Neem de eis niet zomaar over.

2. Iemand wil het label van een veld hernoemen, en iemand anders wil het formaat veranderen van de klantidentificator die vijf systemen al opslaan. Wat verdient meer van je aandacht, en waarom?

De identificator. Het label is goedkoop te veranderen. De identificator zakt voor de omkeerbaarheidstest: moeilijk terug te draaien, en er hangt al veel van af. Besteed aandacht in verhouding tot de kosten van een vergissing. Lees opnieuw Sommige beslissingen zijn goedkoop te veranderen.

3. Een tekstveld is al jaren in gebruik. De business wil er nu een getal in opslaan. Wat is je aanpak?

Verander het niet ter plekke. Zoek uit wat ervan afhangt (Flows, Apex, rapporten, integraties, agents) en wat er met de oude data gebeurt. Meestal: voeg een nieuw veld toe, migreer bewust en faseer het oude uit. Lees opnieuw Wees voorzichtig met het veranderen van het skelet.

4. 1.200 locaties, 100 afspraken per locatie per dag, ongeveer 305 dagen per jaar, twee records per afspraak, vijf jaar bewaren, 30 procent groei. Ongeveer hoeveel records, en waarom doet dat ertoe?

Ongeveer 73 miljoen records in het eerste jaar (36,6 miljoen afspraken, elk twee records), en met groei meer dan 650 miljoen over vijf jaar. Dezelfde functie, een paar nullen meer, een heel andere architectuur. Lees opnieuw Ken je getallen.

5. Een nachtelijke load meldt "voltooid" voor een miljoen records. Hoe weet je dat het werkte?

Je reconcilieert. De ontvangende kant bevestigt elk record dat het opsloeg; de verzender vergelijkt wat het verstuurde met wat bevestigd is. Ontbrekende bevestigingen betekenen dat het niet werkte, wat de jobstatus ook zegt, en vertellen je welke records je opnieuw moet proberen, naar een mens moet doorsturen of waarvoor je een melding moet geven. Lees opnieuw Gedeeltelijk succes is nog steeds falen dat je moet begrijpen.

6. Een community van 15 miljoen Customer Community-gebruikers heeft complexe toegang tot records nodig. Iemand stelt Apex sharing voor. Wat is het probleem?

Het zijn high-volume users: geen rollen, buiten het sharingmodel, dus er is geen sharerecord dat Apex kan schrijven. Toegang komt van sharing sets en share groups. De licentie besliste welke sharinggereedschappen er bestaan. Lees opnieuw Een uitgewerkt voorbeeld: Apex sharing.

7. Een AI-tool genereert in een paar minuten twintig objecten voor een nieuwe app. Wat is nu de taak van de architect?

Beslissen of we er vijf zouden moeten hebben. Het model goed genoeg begrijpen om het te verdedigen: waarom deze objecten en relaties, waar de sleutels en stamgegevens zitten, wat er op schaal gebeurt. De feiten controleren waarop het steunde. Genereren is geen oordelen. Lees opnieuw Goedkope implementatie verplaatst de waarde.

Verder lezen

Section titled “Verder lezen ”