Architekturmønstre

Få mere at vide om veludformet ressourceoptimering → Dine optimeringsansvar

Denne side indeholder omfattende mønstervejledning til arkitektoniske bekymringer, herunder funktionelle enheder, adskillelse af bekymringer, statsstyring, API-styring og meddelelser. Disse mønstre formaterer langsigtet løsningssucces gennem bevidste designbeslutninger om servicegrænser, dataadgangsmønstre og komponentansvar.

Mønstre

Hvor skal du se	Hvad der ser godt ud
Apex-klasser	✅ Serviceklasser følger princippet for enkelt ansvar med navne, der tydeligt angiver formål (AccountService, OrderProcessor, InventoryManager). Hver serviceklasse fokuserer på et domæne eller en forretningsfunktionalitet. Metoder i serviceklasser har enkelte, fokuserede ansvarsområder under 20 linjer.
Udløsere	✅ Udløsere uddelegeres til handlerklasser i stedet for at indeholde forretningslogik direkte. Udløserhåndteringsmønster, der bruges ensartet med tydelige metodenavne efter kontekst (handleBeforeInsert, handleAfterUpdate). Handlerklasser organiserer logik efter udløserbegivenhed med enkelte ansvar pr. metode.
Lightning Web-komponenter	✅ Komponenter følger princippet for enkelt ansvar med tydelige kompatible grænseflader til konfiguration. Hvert LWC fokuserer på et brugergrænsefladeproblem (datavisning, brugerinput, navigation). Komponenter, der er designet til sammensætning, ikke monolithiske implementeringer.
Servicelag	✅ Serviceklasser indkapsler forretningslogik uafhængigt af indgangspunktet (udløser, API, forløb, batch). Den samme serviceklasse håndterer flere kaldekontekster uden duplikering. Servicelaget adskiller forretningsregler fra præsentations- og dataadgangsproblemer.
Genanvendelige komponenter	✅ Komponenter, der er designet til genbrug på tværs af flere projekter og teams. Konfigurationsstyret adfærd ved brug af tilpassede metadatatyper aktiverer adfærdsmæssige ændringer uden kodeimplementering. Handlinger, der kan kaldes, viser Apex som deklarative byggeblokke, der kan bruges fra forløb og ekstern orkestrering.

Anti-mønstre

Hvor skal du se	Hvad ser dårligt ud
Guds klasse	⚡️ Undgå at akkumulere overdreven ansvar i en enkelt klasse. Opdel store klasser (>500 linjer) i fokuserede klasser med enkelte ansvarsområder. Omarranger klasser, når de håndterer flere ikke-relaterede bekymringer (OrderProcessor skal ikke også håndtere afsendelse af mail og rapportering).
Mixed Concerns	⚡️ Undgå at blande udløserlogik, forretningsregler og dataadgang i enkelte klasser. Adskil præsentationslogik fra forretningslogik i controllere. Hold integrationsbestræbelser adskilt fra kernedomænelogik.
Udløserlogik i udløsere	⚡️ Undgå at integrere forretningslogik direkte i udløserfiler. Brug aldrig 300+ linjeudløsere med indbyggede betingelser. Uddeleger altid til handler-klasser med tydelig metodeorganisation efter udløserkontekst.

Mønstre

Hvor skal du se	Hvad der ser godt ud
Forretningslogik	✅ Forretningsregler centraliseret i serviceklasser, ikke spredt på tværs af udløsere, controllere og batchklasser. Domæneklasser indkapsler adfærd på registreringsniveau (validering, standarder, afledte værdier) ensartet, uanset hvordan registreringer indsættes i systemet. Logik genbrugt gennem servicelaget i stedet for duplikeret på tværs af indgangspunkter.
Dataadgang	✅ Dataadgang, der er abstrakt bag lager- eller valgmønsterklasser. SOQL-forespørgsler centraliseres i valgklasser (AccountSelector, OpportunitySelector), hvilket sikrer ensartede feltlister og WHERE-sætninger. Lagringsmønster aktiverer test med falske datakilder uden at ændre forretningslogik.
Interface-kontrakter	✅ Komponenter kommunikerer gennem eksplicitte grænseflader i stedet for implementeringsdetaljer. Apex definerer kontrakter mellem lag. Tilpasset metadatakonfiguration definerer adfærdsmæssige grænser. Platformsbegivenheder leverer meddelelseskontakter mellem producenter og forbrugere.
Modelgrænser	✅ Begrænsede kontekster definerer tydelige ejerskabsgrænser for datamodeller og forretningsregler. Hvert modul ejer dets data, automatisering og forretningslogik. Moduler interagerer gennem definerede API’er i stedet for at dele databaseobjekter direkte. Dokumentationen identificerer tydeligt, hvilket team der ejer hvilke objekter og tjenester.
Afhængighedsforløb	✅ Afhængigheder forløber i en retning (præsentation → forretning → data). Kerneforretningslogik afhænger af intet eksternt og aktiverer uafhængig udvikling. Infrastrukturproblemer (logføring, cachelagring, eksterne API’er) afhænger af forretningslogik gennem grænseflader, ikke omvendt.

Anti-mønstre

Hvor skal du se	Hvad ser dårligt ud
Logisk duplikering	⚡️ Undgå dubletforretningslogik på tværs af udløsere, API-slutpunkter og batchklasser. Centraliser i servicelaget, og genbrug på tværs af indgangspunkter. Når den samme forretningsregel vises i flere klasser, skal du udtrække til den delte tjeneste.
Dataadgang spredt	⚡️ Undgå SOQL-forespørgsler, der er spredt over udløser-, controller- og batchklasser med inkonsekvente feltlister og WHERE-sætninger. Centraliser forespørgsler i vælgerklasser, så du sikrer ensartede mønstre og aktiverer LDV-optimering på et sted.
Forretningslogik i udløsere	⚡️ Undgå valideringsregler, feltberegninger og arbejdsfloworkestrering, der er integreret direkte i udløserkode. Flyt til serviceklasser eller domæneklasser. Hold udløsere tynde, og fokuser kun på uddelegering til relevante handlere.
Forretningslogik i Controllers	⚡️ Undgå komplekse beregninger, validering eller datamanipulering i Aura/LWC-controllermetoder. Controller skal orkestrere kald til servicelaget, ikke implementere forretningsregler direkte.
Cirkulære afhængigheder	⚡️ Undgå pakker eller klasser med cirkulære afhængigheder, hvor A afhænger af B og B afhænger af A. Løs ved at udtrække delte bekymringer i særskilte moduler, invertere afhængighedsretning eller bruge begivenhedsstyret kommunikation til at afbryde kobling.

Mønstre

Hvor skal du se	Hvad der ser godt ud
Platformscache (organisationspartition)	✅ Hyppigt tilgængelige referencedata, der er sat i cache i organisationspartitionen, herunder tilpassede metadataopslag, pluklisteværdier, konfigurationsindstillinger og beregnede resultater af dyre handlinger. Standard TTL konfigureret baseret på datavolatilitet (timer for månedlige referencedata, minutter for ofte opdateret konfiguration). Cachenøglestrategi forhindrer kollisioner på tværs af forskellige datatyper.
Platformscache (sessionspartition)	✅ Brugerspecifikke præferencer, beregnede tilpasningsdata og sessionsomfangstilstand lagret i sessionscache. Sessionscache bruges ikke til data, der skal deles på tværs af brugere. Cachegyldighedsstrategien håndterer brugerpræferenceopdateringer korrekt.
Lightning-datatjeneste	✅ LDS leverer automatisk cachelagring af klientregistreringer for Lightning Web-komponenter. CRUD-standardhandlinger bruger LDS i stedet for tilpassede Apex. LDS eliminerer overflødige serverudflugter og leverer optimistiske opdateringer af brugergrænsefladen. Komponenter bruger delt LDS-cache på tværs af side.
Tilpassede metadatatyper	✅ Konfigurations- og adfærdsregler, der er lagret i tilpassede metadatatyper i stedet for hardcodede i klasser. Tilpassede metadata, der kan implementeres på tværs af miljøer via ændringssæt eller kildestyret udvikling. Ændringer af tilpassede metadata kræver ikke fuld implementeringscyklus. Sæt tilpassede metadataforespørgsler i cache for platform for at opnå ydeevne.

Anti-mønstre

Hvor skal du se	Hvad ser dårligt ud
Forespørgsel i løkke	⚡️ Undgå at køre SOQL i gentagelsesløkker. Forespørg på alle nødvendige registreringer i en enkelt SOQL-erklæring uden for løkker. Organiser resultaterne i Kort efter overordnet id for opslag under iteration. Dette er det enkelt mest almindelige Salesforce-modemønster.
Gentagende forespørgsler	⚡️ Undgå at forespørge på de samme tilpassede metadata, tilpassede indstillinger eller referere til data flere gange pr. transaktion. Forespørg en gang, cachelagr i platformscache eller transaktionens statiske variabel, genbrug på tværs af transaktion.
Missende cachestrategi	⚡️ Undgå gentagne forespørgsler på ofte åbnede referencedata uden cachelagring. Implementer platformscache for tilpassede metadata, konfiguration og beregnede resultater. Definer relevant TTL baseret på datavolatilitet.
Cache uden ugyldiggørelse	⚡️ Undgå cachelagring af data uden at overveje ugyldighedsstrategi. Definer cache TTL, der er relevant for opdateringsfrekvens. Implementer manuel cachefrigivelse, når kildedata ændres, hvis TTL alene er utilstrækkelig.
Ikke-administreret sessionsstat	⚡️ Undgå at antage, at sessionstilstanden bevares på tværs af sidenavigationer uden bekræftelse. Lightning skal håndtere tilstandsopdatering på sideindlæsning. Brug Lightning Data Service til automatisk tilstandssynkronisering.

Mønstre

Hvor skal du se	Hvad der ser godt ud
Løsningsarkitekturplanlægning	✅ Arkitekturplanlægning forekommer før væsentlig investering i opbygning, herunder kravsanalyse (funktionel og ikke-funktionel), styringsbegrænsningsanalyse for forventede datamængder, mønstervalg, der er relevante for krav, og komponentdesign, der definerer større komponenter og grænseflader.
Design mønstervalg	✅ Bevist Salesforce-designmønstre anvendt ensartet: Servicelagsmønster for genbrug af forretningslogik, Repository/Selector-mønster for dataadgangsabstraktion, Strategy-mønster for udskiftelige algoritmer, Domænemønster for adfærd på registreringsniveau, Udløser-handler-mønster for ensartet udløserorganisation.
Arkitektbeslutningsregistreringer	✅ Vigtige arkitektoniske beslutninger, der er dokumenteret i ADR’er, der er lagret i versionskontrol. ADR’er registrerer kontekst (forretningsdrivere, tekniske begrænsninger), beslutning (hvad der blev valgt), overvejede alternativer (hvorfor andre blev afvist) og konsekvenser (udløb, teknisk gæld, tilbagesøgningsudløsere).
Build vs Buy Evaluation	✅ AppExchange evaluering foregår tilpassede udviklingsbeslutninger ved hjælp af samlet ejeromkostningsanalyse. Evalueringskriterier inkluderer strategisk værdi (konkurrencedygtig differentiator kontra råvare), TCO-sammenligning (opbygningsindsats, vedligeholdelsesomkostninger, opgraderingskostnader), integrationskompleksitet og afslutningsomkostninger, hvis løsningen viser sig utilstrækkelig.
Governor Limit Analysis	✅ Arkitektonisk planlægning identificerer, hvilken styring der begrænser det mest begrænsende design i henhold til forventede datamængder og transaktionsmønstre. Transaktioner, der er designet til at forbruge mindre end 80 % af enhver enkelt styringsbegrænsning under spidsbetingelser. Margen, der er bygget til vækst, fremtidige funktioner og uventede anvendelsesmønstre.
Risikovurdering	✅ Tekniske risici identificeret for arkitektoniske tilgange, der skubber platformsgrænser. Begrænsningsstrategier, der er defineret for hver væsentlig risiko. Prototype- eller proof-of-concept-arbejde validerer antagelser for tekniske tilgange med høj risiko før fuld opbygningsengagement.

Anti-mønstre

Hvor skal du se	Hvad ser dårligt ud
Ingen planlægning	⚡️ Undgå at starte opbygning uden at analysere datamængder, styringsbegrænsninger eller mønstervalg. Arkitekturplanlægningsværkstedet bør identificere nøglebegrænsninger, vælge mønstre og validere op mod styringsbegrænsninger, før opbygningen begynder.
Udokumenterede afgørelser	⚡️ Undgå arkitektoniske beslutninger, der træffes i møder uden at registrere kontekst, rationalitet, alternativer og konsekvenser. Brug arkitektoniske beslutningsregistreringer, der er lagret i versionskontrol, der bevarer beslutningskonteksten for fremtidige teammedlemmer.
Ingen opbygning kontra købsanalyse	⚡️ Undgå at opbygge tilpassede løsninger uden AppExchange evaluering. Evaluer top 3-5 relevante pakker før tilpasset udvikling. Sammenlign TCO inklusive implementeringsindsats, vedligeholdelse, opgraderingsomkostninger og afslutningsomkostninger.
Sub-engineering	⚡️ Undgå kun at designe til aktuelle datamængder uden vækstprojicering. Projekter datavækst over 2-3 år. Design forespørgselsmønstre med selektivitet valideret op mod 5-10 gange aktuelle mængder. Opbyg arkitektonisk margen for vækst.

Mønstre

Hvor skal du se	Hvad der ser godt ud
Anden generation af administrerede pakker (2GP)	✅ 2GP bruges til nye administrerede pakker, der kræver navneområdeisolering, AppExchange og IP-beskyttelse. Kildestyret udviklingsarbejdsflow med modulær applikationsudvikling. Pakkeafhængigheder administreres eksplicit. Versioner, der er frigivet med semantisk versionering.
Ulåste pakker	✅ Ulåste pakker, der bruges til interne virksomhedsapplikationer, der kræver modularitet uden navneområdebegrænsninger. Uafhængig implementering af pakker uden organisationsafhængige artefakter. Pakkeafhængigheder spores for korrekt implementeringsrækkefølge. Versionsstrategi, der er defineret for interne pakker.
Modelgrænser	✅ Ryd ejerskabsgrænser, der er defineret for hver pakke. Hver pakke ejer sin datamodel, forretningsregler og automatisering. Pakker interagerer gennem definerede grænseflader i stedet for direkte objektadgang. Dokumentation identificerer pakkeejerskab og kontrakter mellem pakker.