Arkitekturmønstre
Lær mer om velbygd ressurs- og kostnadsoptimalisering → Dine optimaliseringsansvar
Denne siden gir omfattende mønsterveiledning for arkitektoniske problemer, inkludert funksjonelle enheter, adskillelse av problemer, delstatsbehandling, API-behandling og meldinger. Disse mønstrene former langsiktig løsningssuksess gjennom bevisst utformingsbeslutninger om tjenestegrenser, datatilgangsmønstre og komponentansvar.
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Apex-klasser | ✅ Tjenesteklasser følger prinsippet for enkeltansvar med navn som tydelig angir formål (AccountService, OrderProcessor, InventoryManager). Hver tjenesteklasse fokuserer på ett domene eller en forretningskapasitet. Metoder i serviceklasser har enkelt, fokusert ansvar under 20 linjer. |
| Utløsere | ✅ Utløsere delegeres til behandlerklasser i stedet for å inneholde forretningslogikk direkte. Utløserbehandlermønster som brukes konsistent med tydelige metodenavn etter kontekst (handleBeforeInsert, handleAfterUpdate). Behandlingsklasser organiserer logikk etter utløserhendelse med enkeltansvar per metode. |
| Lightning-nettkomponenter | ✅ Komponenter følger prinsippet for enkeltansvar med tydelige egengrensesnitt for konfigurasjon. Hver LWC fokuserer på én brukergrensesnittproblem (dataversjon, brukerinndata, navigering). Komponenter utformet for sammensetting, ikke monolittiske implementeringer. |
| Tjenestelag | ✅ Tjenesteklasser innkapsler forretningslogikk uavhengig av inngangspunktet (utløser, API, Flyt, batch). Den samme serviceklassen håndterer flere kallkontekster uten duplisering. Tjenestelag skiller forretningsregler fra presentasjons- og datatilgangsproblemer. |
| Gjenbrukbare komponenter | ✅ Komponenter utformet for gjenbruk på tvers av flere prosjekter og team. Konfigurasjonsdrevet virkemåte som bruker tilpassede metadatatyper, aktiverer atferdsendringer uten kodedistribusjon. Kallbare handlinger viser Apex som deklarative byggeblokker som kan brukes fra flyt og ekstern orkestrering. |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Gudklasse | ⚡️ Unngå å akkumulere for mye ansvar i én enkelt klasse. Del opp store klasser (> 500 linjer) i fokuserte klasser med enkeltansvar. Omorganiser klasser når de håndterer flere ikke-relaterte problemer (OrderProcessor bør heller ikke håndtere e-postsending og rapportering). |
| Blandte bekymringer | ⚡️ Unngå å blande utløserlogikk, forretningsregler og datatilgang i enkeltklasser. Skill presentasjonslogikk fra forretningslogikk i kontroller. Hold integrasjonsproblemer atskilt fra kjernedomenelogikk. |
| Utløserlogikk i utløsere | ⚡️ Unngå å bygge inn forretningslogikk direkte i utløserfiler. Bruk aldri 300+ linjeutløsere med nestede betingelser. Delegere alltid til behandlerklasser med tydelig metodeorganisasjon etter utløserkontekst. |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Forretningslogikk | ✅ Forretningsregler sentralisert i serviceklasser, ikke fordelt på tvers av utløsere, controllere og gruppeklasser. Domeneklasser innkapsler virkemåte på postnivå (validering, standardverdier, utledede verdier) konsistent uavhengig av hvordan poster kommer inn i systemet. Logikk som brukes på nytt gjennom tjenestelaget i stedet for duplisert på tvers av inngangspunkter. |
| Datatilgang | ✅ Datatilgang abstrakt bak klasser for repositorium eller velgermønster. SOQL-spørringer sentraliseres i velgerklasser (AccountSelector, OpportunitySelector) som sikrer ensartede feltlister og WHERE-setninger. Repositoriemønster aktiverer testing med mock-datakilder uten å endre forretningslogikk. |
| Grensesnittkontrakter | ✅ Komponenter kommuniserer via eksplisitte grensesnitt i stedet for implementeringsdetaljer. Apex definerer kontrakter mellom lag. Tilpasset metadatakonfigurasjon definerer virkemåtenes grenser. Plattformhendelser sørger for meldingskontrakter mellom produsenter og forbrukere. |
| Modulgrenser | ✅ Begrensede kontekster definerer tydelige eierskapsgrenser for datamodeller og forretningsregler. Hver modul eier sine egne data, automatisering og forretningslogikk. Moduler samhandler via definerte API-er i stedet for å dele databaseobjekter direkte. Dokumentasjonen identifiserer tydelig hvilket team som eier hvilke objekter og tjenester. |
| Avhengighetsflyt | ✅ Avhengigheter-flyt i én retning (presentasjon → forretning → data). Kjerneforretningslogikk avhenger ikke av noe eksternt og aktiverer uavhengig utvikling. Infrastrukturproblemer (logging, bufring, eksterne API-er) er avhengig av forretningslogikk via grensesnitt, ikke omvendt. |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Logisk duplisering | ⚡️ Unngå duplisering av forretningslogikk på tvers av utløsere, API-endepunkter og gruppeklasser. Sentraliser i tjenestelaget og gjenbruk på tvers av inngangspunkter. Når den samme forretningsregelen vises i flere klasser, trekker du ut til delt tjeneste. |
| Datatilgang spredt | ⚡️ Unngå SOQL-spørringer som er spredt over utløser-, kontroller- og gruppeklasser med inkonsekvente feltlister og WHERE-setninger. Sentraliser spørringer i velgerklasser for å sikre konsistente mønstre og aktivere LDV-optimalisering på ett sted. |
| Forretningslogikk i utløsere | ⚡️ Unngå valideringsregler, feltberegninger og arbeidsflytorkestrering innebygd direkte i utløserkode. Flytt til serviceklasser eller domeneklasser. Hold utløsere tynne, fokusert bare på å delegere til de riktige behandlerne. |
| Forretningslogikk i kontroller | ⚡️ Unngå komplekse beregninger, validering eller datamanipulering i Aura/LWC-kontrollermetoder. Kontrollere bør orkestrere kall til tjenestelag, ikke implementere forretningsregler direkte. |
| Sirkulære avhengigheter | Unngå pakker eller klasser med sirkulære avhengigheter der A avhenger av B og B avhenger av A. Løs ved å trekke ut delte bekymringer i separate moduler, reversere avhengighetsretningen eller bruke hendelsesdrevet kommunikasjon til å bryte koblingen. |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattformbuffer (organisasjonspartisjon) | ✅ Ofte tilgjengelige referansedata bufret i organisasjonspartisjon, inkludert tilpassede metadataoppslag, valglisteverdier, konfigurasjonsinnstillinger og beregnede resultater av dyre operasjoner. Standard TTL konfigurert basert på datavolatilitet (timer for månedlige referansedata, minutter for ofte oppdaterte konfigurasjoner). Buffernøkkelstrategi hindrer kollisjoner på tvers av forskjellige datatyper. |
| Plattformbuffer (øktpartisjon) | ✅ Brukerspesifikke preferanser, beregnede tilpassingsdata og status for øktomfang lagret i øktbuffer. Øktbuffer brukes ikke til data som skal deles på tvers av brukere. Bufreaktiveringsstrategi håndterer oppdateringer av brukerpreferanser riktig. |
| Lightning-datatjeneste | ✅ LDS tilbyr automatisk postbufring på klientsiden for Lightning. Standard CRUD-operasjoner bruker LDS i stedet for tilpassede Apex. LDS eliminerer overflødige serveravrundinger og gir optimistiske brukergrensesnittoppdateringer. Komponenter benytter delt LDS-buffer på tvers av sider. |
| Tilpassede metadatatyper | ✅ Konfigurasjons- og atferdsregler lagret i tilpassede metadatatyper i stedet for hardkodet i klasser. Tilpassede metadata som kan distribueres på tvers av miljøer via endringssett eller kildedrevet utvikling. Endringer i tilpassede metadata krever ikke full distribusjonssyklus. Bufre tilpassede metadataspørringer i plattformbuffer for ytelse. |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Spørring i sløyfe | ⚡️ Unngå å utføre SOQL i gjentagelsessykluser. Spørre alle nødvendige poster i en enkelt SOQL-setning utenfor sløyfer. Organiser resultater i Kart etter overordnet ID for oppslag under gjentagelse. Dette er det vanligste Salesforce-anti-mønsteret. |
| Gjentagende spørringer | ⚡️ Unngå å spørre mot samme tilpassede metadata, tilpassede innstillinger eller referere til data flere ganger per transaksjon. Spørring én gang, bufring i plattformbuffer eller transaksjonsstatisk variabel, gjenbruk på tvers av transaksjon. |
| Fraværende bufferstrategi | ⚡️ Unngå å spørre ofte-tilgang referansedata gjentatte ganger uten bufring. Implementer Plattformbuffer for tilpassede metadata, konfigurasjon og beregnede resultater. Definer riktig TTL basert på datavolatilitet. |
| Bufferen uten ugyldiggjøring | ⚡️ Unngå bufring av data uten å vurdere en ugyldiggjørelsesstrategi. Definer buffer-TTL som er riktig for oppdateringsfrekvens. Implementer manuell bufferfjerning når kildedata endres hvis TTL alene er utilstrekkelig. |
| Uadministrert øktstatus | ⚡️ Unngå å anta at øktstatusen beholdes på tvers av sidenavigeringer uten bekreftelse. Lightning skal håndtere statusoppdatering ved sideinnlasting. Bruk Lightning Data Service til automatisk synkronisering av status. |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Løsningsarkitekturplanlegging | ✅ Arkitekturplanlegging skjer før betydelige bygginvesteringer, inkludert behovsanalyse (funksjonell og ikke-funksjonell), styringsgrensenalyse for forventede datavolumer, mønstervalg som passer til kravene, og komponentutforming som definerer hovedkomponenter og grensesnitt. |
| Design mønstervalg | ✅ Bekreftede Salesforce-utformingsmønstre brukt konsekvent: Tjenestelagsmønster for gjenbruk av forretningslogikk, Oppbevarings-/velgermønster for datatilgangsabstraksjon, Strategimønster for utskiftbare algoritmer, Domene-mønster for virkemåte på postnivå, Utløserbehandlingsmønster for konsistent utløserorganisasjon. |
| Arkitekturbeslutningsposter | ✅ Viktige arkitektoniske beslutninger dokumentert i ADR-er lagret i versjonskontroll. ADR-er fanger opp kontekst (forretningsdrivere, tekniske begrensninger), beslutning (hva som ble valgt), vurderte alternativer (hvorfor andre ble avvist) og konsekvenser (avtaler, teknisk gjeld, gjenopptagelsesutløsere). |
| Bygge vs Kjøp Evaluering | ✅ AppExchange evaluering foregår tilpassede utviklingsbeslutninger ved bruk av total kostnad for eierskap analyse. Evalueringskriterier inkluderer strategisk verdi (konkurranseforskjell kontra råvare), TCO-sammenligning (byggeinnsats, vedlikehold, oppgraderingskostnader), integrasjonskompleksitet og utgangskostnad hvis løsningen viser seg å være utilstrekkelig. |
| Governorgrenseanalyse | ✅ Arkitektonisk planlegging identifiserer hvilken styrer som begrenser utformingen mest gitt forventede datavolumer og transaksjonsmønstre. Transaksjoner utformet for å forbruke mindre enn 80 % av en enkeltstyringsgrense under toppbetingelser. Margin som er bygd for vekst, fremtidige funksjoner og uventede bruksmønstre. |
| Risikobehandlingen | ✅ Tekniske risikoer identifisert for arkitektoniske tilnærminger som overfører plattformgrenser. Avbøtende strategier definert for hver betydelig risiko. Prototype- eller konseptbekreftelsesarbeid validerer forutsetninger for tekniske tilnærminger med høy risiko før full byggeforpliktelse. |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Ingen planlegging | ⚡️ Unngå å begynne å bygge uten å analysere datavolumer, styringsgrenseinnvirkninger eller mønstervalg. Arkitekturplanleggingsverksted bør identifisere viktige begrensninger, velge mønstre og validere mot styringsgrenser før byggingen begynner. |
| Udokumenterte avgjørelser | ⚡️ Unngå arkitektoniske beslutninger som tas i møter uten å fange opp kontekst, grunnlag, alternativer og konsekvenser. Bruk Beslutningsposter for arkitektur lagret i versjonskontroll for å beholde beslutningskonteksten for fremtidige teammedlemmer. |
| Ingen bygg vs kjøp analyse | Unngå å bygge tilpassede løsninger uten AppExchange evaluering. Evaluer de 3-5 mest relevante pakkene før tilpasset utvikling. Sammenlign TCO, inkludert implementeringsinnsats, vedlikehold, oppgraderingskostnader og utgangskostnader. |
| Ingeniørfag | ⚡️ Unngå å utforme bare for gjeldende datavolumer uten vekstprojeksjon. Prosjektdatavekst over 2-3 år. Utform spørringsmønstre med selektivitet validert mot 5-10x gjeldende volumer. Bygg arkitektonisk margin for vekst. |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Andregenerasjons administrerte pakker (2GP) | ✅ 2GP brukt til nye administrerte pakker som krever navneområdeisolering, AppExchange og IP-beskyttelse. Kildedrevet utviklingsarbeidsflyt med modulær programutvikling. Pakkeavhengigheter behandles eksplisitt. Versjoner utgitt med semantisk versjonsbehandling. |
| Ulåste pakker | ✅ ulåste pakker som brukes til interne virksomhetsprogrammer som krever modularitet uten navneområdebegrensninger. Uavhengig distribusjon av pakker uten organisasjonsavhengige artefakter. Pakkeavhengigheter spores for riktig distribusjonsbestilling. Versjonsstrategi definert for interne pakker. |
| Modulgrenser | ✅ Fjern eierskapsgrensene som er definert for hver pakke. Hver pakke eier sin datamodell, forretningsregler og automatisering. Pakker samhandler via definerte grensesnitt i stedet for direkte objekttilgang. Dokumentasjonen identifiserer pakkeeierskap og kontrakter mellom pakker. |