Læs om vores opdateringsplaner heri.

Sammensatte løsninger justeres hurtigt og med større stabilitet. Et system, der er bygget til at kunne sammensættes, er bygget i meningsfulde enheder eller byggeblokke, der kan fungere fint med hinanden og nemt kan byttes ind og ud af service. Opbygning af komponerbarhed i et system giver dig mulighed for at introducere nye funktioner eller fjerne teknisk gæld ved at omstrukturere eller sammensætte individuelle enheder i et system. Sammensætbarhed aktiverer hurtigere, mere forudsigelige leveringscyklusser og -versioner, da teams kan fokusere på at opbygge og levere meningsfulde funktioner via mindre mængder ændringer.

Sammensatte systemer gør det muligt for virksomheder at tilpasse sig hurtigere og med større stabilitet – uanset om stimuli er interne for forretningen eller forårsaget af eksterne faktorer. Sammensætbarhed gør systemer mere modstandsdygtige og kan bidrage til at gøre løsninger og arkitektoniske mønstre mere hensigtsmæssige.

Du kan gøre dine Salesforce-løsninger mere komponerbare ved at opbygge tre nøglevaner: adskillelse af bekymringer, interoperabilitet og pakbarhed. Nedenfor kan du se relationen mellem disse vaner på to måder: for en enkelt enhed i et sammensat system og på tværs af flere enheder i et sammensat system.

En enkelt, sammensat enhed:

Et komposerbart system:

Et grundlæggende begreb inden for software- og systemarkitektur, separation af bekymringer indebærer at identificere forskellige bekymringer inden for et større system, der kan adskilles i modulære enheder. Opnåelse af en stærk adskillelse af bekymringer i et system kræver oprettelse af meningsfulde enheder for applikationslogik og funktioner i hele systemet. Mindre enheder gør det nemmere for appleverings- og vedligeholdelsesteams at forstå, hvordan og hvor der skal foretages ændringer med minimal afbrydelse af det større system. Mindre enheder gør det også tydeligere, hvordan og hvor du skal fokusere arbejdet, når du håndterer teknisk gæld, og bidrager til den generelle læselighed af dit system.

Du kan opbygge en bedre adskillelse af bekymringer i din Salesforce-organisation ved at orienteres til forretningsfunktioner og administrationstilstand.

For Salesforce-systemer anvender den bedste tilgang til adskillelse af bekymringer et forretningsorienteret perspektiv til at identificere og organisere modulære enheder (eller funktioner) i systemet. Dette er i modsætning til en teknikfokuseret visning, der identificerer enheder baseret på deres tekniske funktion. Et forretningsorienteret perspektiv i adskillelse af bekymringer kræver organisering af koden og tilpasninger i dit system baseret på den service, de leverer til forretnings- og forretningsbrugere. Hvis du anvender denne tilgang, betyder det ikke, at du ignorerer potentialet for overflødige eller dublettekniske funktioner i et system. Det betyder snarere, at tekniske tjenester er tydeligt tilknyttet et organisatorisk princip, der i sidste ende er gennemsigtigt for forretningen.

Orientering til forretningsfunktioner hjælper med til at sikre, at overførsler mellem forretningsanalyser og opdagelsesteams til leveringsteams er så ukomplicerede som muligt. Hvis appkonstruktører ikke har nogen idé om, hvor deres arbejdsenheder knyttes til din sammensætningsarkitektur, har du et rod, ikke et sammensat applandskab. Uklare tilknytninger mellem den sluttilstand, der kræves af forretningen, og de modulære enheder i en organisation øger også sandsynligheden for, at udviklingsteams eller leverandører opbygger overflødige funktioner i systemet.

Overvej følgende for at orientere funktionelle enheder til forretningsfunktioner:

• Begynd med opgaver, der skal udføres. Fokuser på de job, der skal udføres (JTBD) for brugere og selve forretningen. Pioneret af Tony Ulwick, centrerer JTBD-tilgangen sig om at forstå det "job" eller det sande formål, som personer forsøger at opnå ved at bruge et produkt eller en tjeneste. Det er et højere niveau af abstraktion end brugerens rollerelaterede opgaver eller de individuelle trin i en forretningsproces. F.eks. kan opgaver som dubletkontroller og adressevalideringer falde inden for en højere rækkefølgefunktion som "opret en enkelt visning af kunden". Når du har en klar fornemmelse af disse forretningsfunktioner i højere rækkefølge, kan du begynde at tilknytte dele af dit system til dem.
• Orientering til kapaciteter, ikke rapporteringsstrukturer. Det interne hierarki for dine forretningsenheder er ikke et proxy for meningsfulde funktioner eller job, der skal udføres. Det interne hierarki i din forretning har en væsentlig påvirkning på processer og teamstrukturer (for ikke at nævne budgetter). Det er vigtige logistiske overvejelser. Men de funktionelle behov i forretningen fungerer på et højere niveau af abstraktion end logistik. Hvis du opretter et modul til at vise en rapportstruktur i stedet for en funktion i højere rækkefølge, skal du være opmærksom på, at du måske skal udføre yderligere trin for at identificere, hvordan dette modul er relateret til forretningsfunktioner.
• Vær iterativ. Start med at oprette partnerskab med forretningen for at identificere, hvilken funktionalitet der kan fungere for et minimalt levedygtigt produkt (MVP). Når du identificerer en funktion, skal du starte med at opbygge denne MVP. Når du opbygger, skal du identificere de processer, metadata og begivenheder eller meddelelser, der er centrale for den funktionelle enhed, du opretter. Identificer alle processer, metadata og begivenheder eller meddelelser, der er eksterne afhængigheder. Når flere funktionelle enheder designes, skal du implementere API-styring og afhængighedsstyring for at opbygge enheder, der fungerer godt med hinanden (i stedet for at opbygge enkeltstående enheder).

Listen over mønstre og anti-mønstre nedenfor viser, hvordan korrekt (og dårlig) orientering til forretningsfunktioner ser ud i en Salesforce-løsning. Du kan bruge disse til at validere dine designs, før du opbygger, eller identificere områder i dit system, der skal omstruktureres.

Hvis du vil vide mere om de værktøjer, der er tilgængelige fra Salesforce for at hjælpe dig med bedre at orientere dig i forretningsfunktioner, kan du se Værktøjer, der er relevante for sammensatte.

Statsstyring fokuserer på flytning af oplysninger i hele systemet på forskellige tidspunkter. Effektiv tilstandsstyring gør det muligt for applikationer at håndtere komplekse forløb af data eller interaktioner med et minimum af uplanlagte eller ubestemte resultater. Administration af tilstanden i en modulær Salesforce-organisation betyder opbygning af tydelige stier for logiske forløb i og mellem enheder samt smarte stier for ikke-planlagt kørselsadfærd. Statsstyring gør det muligt at danne sammenhængende streams af logik fra modulære Salesforce-applikationsenheder. I de fleste tilfælde kræver dette interoperabilitet for at strukturere informationsforløbet mellem enheder.

Problemer med at administrere tilstanden på tværs af løst tilknyttede enheder fører ofte til monolitisk applikationsudvikling i Salesforce. Du kan se dette i store "monoforløb", som er bygget i et forsøg på at orkestrere en kompleks proces i et enkelt forløb. Et andet eksempel er massive Apex-klasser, der orkestrerer komplekse processer gennem spaghetti-kode, eller en lang række af engangsmetoder. Disse typer af applikationsarkitekturer gør omstrukturering og fejlretning vanskelig og øger introduktionstider for nye teammedlemmer eller leverandører. De reducerer også værdien af de applikationer, der leveres til forretningen, da funktionalitet ikke kan genbruges.

Overvej følgende for at administrere tilstanden på tværs af en modulær Salesforce-organisation:

• Bestem, hvornår du vil bruge statsløse mod statsløse mønstre. Statsmæssige mønstre bevarer oplysninger på tværs af en kørselssti, ikke statløse mønstre. I et løst tilknyttet system gør statløse mønstre det muligt for komponenter at blive omstruktureret hurtigere og med færre bivirkninger. Men mønstre uden stat er ikke relevante for alle anvendelsessituationer. Hvis du opbygger komponenter til datahandlinger, kan tilstandsmønstre hjælpe med dataintegritet og ensartethed i alle dine systemer. Brug et tilstandsmønster, hvis din komponent opfylder et af følgende kriterier:
  • Bevidsthed om placering i en større kørselssti er vigtig for komponentens adfærd
  • Komponentens adfærd skal ændres baseret på resultaterne af en downstream-handling (f.eks. skal den ændre kørsel baseret på tilbagerulnings-/fejlmeddelelser/succesmeddelelser fra downstream-komponenter)
  • Komponenten skal vente på svar fra et eksternt eller downstream-system for at afslutte sit arbejde
• Opret meningsfulde kategorier for statsmæssige oplysninger. Stats er et tvetydigt udtryk, der kan anvendes på en så dyb og bred vifte af oplysninger i (og uden for) en Salesforce-organisation, at selve udtrykket er næsten meningsløst. Et nødvendigt første trin til at opbygge tilstandsmønstre er derfor at skabe meningsfulde kategorier for de vigtigste tilstandsudførelsestider (eller typer af tilstandsadfærd) i dit system. Nogle kategorier, du bør overveje:
  • Navigation og formularer
  • Databasehandlinger
  • Batch- og massehandlinger
  • Fejl
• Definer datarelaterede tilstande i form af databasetransaktioner. Platformens indbyggede adfærd vil begrænse de fleste statsovervejelser for data i Salesforce. Forsøg ikke at håndtere eller omgå denne adfærd. Design til og med den. Design løsninger, der minimerer eller eliminerer distribueret transaktionslogik. (Se datahåndtering for at få flere oplysninger).
• Identificer tilstande, der forekommer i (og på tværs af) funktionelle enheder. Når du samler funktionelle enheder i større systemer, skal du være opmærksom på, hvornår du blander statusløs og statfuld komponentadfærd og forhindre kombinationer, der kan oprette endeløse løkker eller huller i behandling.
• Find aftaler. Overvej, hvilke meddelelses- eller eventeringsmønstre komponenterne vil bruge til at overføre statsrelaterede data til en anden del af systemet. Sørg for, at du opbygger transaktionsbevidsthed og håndtering i dine komponenter. Inkluder ikke nogen distribueret transaktionslogik i dine afleveringer.
• Opret tilknytninger mellem dine procesdiagrammer og tilstande. Procesdiagrammer viser de trin, der flytter oplysninger gennem dit system på forskellige tidspunkter. Et tilstandsdiagram viser de faktiske ændringer i oplysningerne (tilstanden). Brug metadatafodsdelen af Salesforce Diagrammer-figurer til at registrere den skiftende tilstand af oplysninger i hvert trin af din proces. Hvis du adskiller procesdiagrammer og tilstandsdiagrammer, skal du sørge for at linke dem. Dette koncept bør ikke forveksles med at registrere den aktuelle og fremtidige tilstand af processer eller systemlandskaber under design og implementering, da det ikke handler om de oplysninger, der flytter gennem systemet.

Listen over mønstre og anti-mønstre nedenfor viser, hvordan korrekt (og dårlig) statsstyring ser ud i en Salesforce-løsning. Du kan bruge disse til at validere dine designs, før du opbygger, eller identificere steder i dit system, der skal omstruktureres.

Hvis du vil vide mere om Salesforce-værktøjer til administration af tilstand, kan du se Værktøjer, der er relevante for sammensat.

Følgende tabel viser et udvalg af mønstre, der skal søges efter (eller opbygges) i din organisation, og anti-mønstre, der skal undgås eller målrettes for rettelse.

✨ Oplev flere mønstre til adskillelse af bekymringer i Pattern & Anti-Pattern Explorer.

I et system, der er udarbejdet med henblik på interoperabilitet, kan komponenter udveksle oplysninger og samarbejde effektivt. Interoperabilitet er en nøgle til at gøre et modulært system komponerbart i stedet for isoleret. Interoperabilitet kan være vanskelig at opnå i et løst sammenkoblet system. Du skal etablere standarder for ensartede integrationsmetoder, der ikke underminerer uafhængigheden mellem enheder og den overordnede opdeling af bekymringer på tværs af systemet.

Interoperabilitet påvirker også kvaliteten af dine brugeroplevelser. Dine brugere forventer, at data, der er oprettet i et område (f.eks. bestillingsoplysninger), kan bruges i et andet (f.eks. marketingkampagner), og dine konstruktører forventer, at hvis de lærer at gøre noget (f.eks. opbygge et forløb eller godkende til en API), vil de finde velkendte teknikker, der fungerer, når de flytter videre til det næste problem. Hvis du ikke kan designe interoperabilitet, resulterer det i redundante arkitekturer, replikerede data, procesineffektiviteter og øgede udviklings- og supportomkostninger.

Du kan oprette interoperabilitet i modulære systemer med meddelelser og begivenheder samt med API-styring.

Meddelelser og begivenheder er to måder, hvorpå du kan aktivere komponenter på tværs af et system til at sende og modtage oplysninger. I forhold til det indhold, de kan indeholde, minder begivenheder og meddelelser om hinanden. En vigtig forskel er afsenderens adfærd. En komponent, der sender en meddelelse, sender typisk data til en bestemt destination og venter på en eller anden form for svar fra modtageren. I modsætning hertil sender en komponent en begivenhed, når der er sket noget. Der er ingen specifik destination eller en forventning om et svar. Disse forskelle i adfærd understøtter forskellige kommunikationsmønstre. Meddelelser understøtter kommunikationsmønstre uden stat, og begivenheder understøtter kommunikationsmønstre uden stat. (Se Statsadministration for mere om denne sondring.)

Det er vigtigt at justere teams om protokoller og bruge sager til meddelelser og begivenheder. Uklare standarder kan resultere i en blanding af mønstre på tværs af dit system, hvilket fører til:

• Problemer med ydeevne og skalerbarhed, hvor de forkerte mønstre anvendes på en bestemt anvendelsessituation
• Inkonsekvent behandling, der får systemet til at se ustabile ud for slutbrugere
• Længere fejlfindingstider og mere komplekse vedligeholdelsesprocesser

Overvej følgende, når du designer meddelelser og begivenheder for at oprette mere løst tilknyttede strukturer i din Salesforce-organisation:

• Identificer synkroniserings- og asynkroniseringsanvendelsessituationer. Begivenheder tillader løst tilknyttet, statløs og asynkron kommunikation på tværs af et system. Meddelelser giver mulighed for mere kontrollerede, tilstandsmæssige og synkrone kommunikationsmønstre. Når du beslutter, hvornår du vil bruge meddelelser eller begivenheder, skal du beslutte, om din kommunikation skal være synkron (og potentielt blokerende) kontra asynkron og ikke-blokerende.
• Definer datastrukturer omhyggeligt. Strukturen af de oplysninger, som komponenter overfører mellem sig, er en vigtig del af at bevare et løst tilknyttet system administrerbart og sammenhængende. (Se API Management for at få mere at vide om dette). En vigtig overvejelse, når du designer en meddelelse eller begivenhed, er, hvor ofte strukturen af oplysningerne skal ændres. Når en meddelelse eller begivenhedsstruktur er defineret og implementeret i dit system, kan det være vanskeligt at håndtere opdateringer – især hvis begivenheden eller meddelelsen allerede bruges til at sende oplysninger til et eksternt system.
• Ret størrelse beskeder. Generelt er det en bedste fremgangsmåde at holde meddelelsesstørrelser små. Der er dog også en afbalanceringshandling mellem meddelelses størrelse og meddelelses volumen. Systemer kan behandle mindre mængder af data hurtigere. Handlingen med behandling leveres med en mængde ekstra overhead, da modtagere skal pakke ud, fortolke og bestemme, hvad de skal gøre med de oplysninger, de har modtaget. Disse trin kan tage en ubetydelig mængde tid at fuldføre, men de kan opbygge og skabe en byrde på systemer på skala. Undgå designs, der kræver, at komponenter i systemet behandler mange små meddelelser i rækkefølge for at fuldføre et stykke arbejde. Hvis du vil justere størrelsen på dine meddelelser, skal du overveje at designe den mindste mængde af downstream-komponenter, der skal behandle og reagere på de oplysninger, de er sendt, uden også at antage, at hver downstream-komponent vil kunne anmode om eller behandle adskillige opfølgningsmeddelelser.
• Design til skalerbarhed. Løbende tilknyttede komponenter kan gøre det nemmere at skalere din arkitektur. Eliminering af krydskomponentafhængigheder gør det muligt for teams at arbejde på at forbedre ydeevnen eller skalerbarheden af enhver individuel komponent med minimale virkninger på de andre. Men løst sammenkoblede komponenter skaber også stor kompleksitet i din arkitektur (især når det gælder administration af tilstanden). Identificer processer, der skal have mere tæt tilknyttet logik eller afhængigheder af gyldige brugeroplevelsesårsager eller dataintegritetsårsager – og forsøg ikke at introducere asynkroniserede/begivenhedsbaserede mønstre i disse processer. Brug i stedet synkroniserings-/meddelelsesbaserede mønstre og korrekt fejlhåndtering.

Listen over mønstre og anti-mønstre nedenfor viser, hvordan korrekt (og dårlig) meddelelser og begivenheder ser ud i en Salesforce-løsning. Du kan bruge disse til at validere dine designs, før du opbygger, eller identificere steder i dit system, der skal omstruktureres.

Hvis du vil vide mere om Salesforce-meddelelser og begivenhedsværktøjer, kan du se Værktøjer, der er relevante for sammensatte. Hvis du ønsker flere oplysninger om valg af et begivenhedsmønster eller et værktøj til en given anvendelsessituation, kan du se Arkitektens vejledning til begivenhedsstyret arkitektur med Salesforce.

Opbygning af korrekt API-styring i en Salesforce-løsning gør det muligt for individuelle komponenter i dit system at følge forudsigelige kommunikationsmønstre. Salesforce leverer indbyggede, sikre API'er, der kan bruges til kommunikation med systemer uden for Salesforce. (Hvis du ønsker flere oplysninger om Salesforce Platform-API'er, kan du se Grundlæggende arkitektur.)

Effektiv API-styring i Salesforce-løsninger er nøglen til opbygning af virkelig komponerbare arkitekturer. Den aktiverer komponenter i en Salesforce-organisation til at sende og modtage oplysninger effektivt. Det gør det også muligt for løsningskonstruktører at følge tydelige protokoller for, hvordan de komponenter, de opbygger, kommunikerer med andre komponenter i systemet og hjælper dem med at identificere dårlige implementeringer tidligt. Desuden gør det det muligt for løsningskonstruktører mere indsnævret at fokusere på den bestemte komponent, som de opbygger eller omstrukturerer, hvilket øger produktiviteten og kvaliteten.

API-styring på virksomhedsniveau er et separat emne – og opnås bedst med et omfattende API-styringsværktøj. (For mere om MuleSoft-perspektivet om dette emne kan du se Hvad er API Management?).

Overvej følgende for at opbygge API-styringsfunktioner i dine Salesforce-løsninger:

• Tænk på API'er som forudsigelige mønstre eller kontrakter til kommunikation. Datatypen for input- eller outputvariabler, variabelnavne, de oplysninger, der skal (eller ikke skal) vises i et givet mønster – disse er nøglerne til effektiv API-styring. Disse definitioner skal vises i dine designstandarder, og teams skal kunne finde ud af, hvordan disse definitioner er blevet implementeret i bestemte dele af dit system via din dokumentation. En måde at se problemer med at flette ændringer fra ny udvikling i et integrationsmiljø er at se på dem som bevis for, hvor du har dårlig implementeret API-kommunikation (eller måske slet ingen API-definition).

• Begræns ikke din tænkning om API'er til kun at kode. Hvad der definerer en API i denne kontekst er ensartetheden af meddelelsesstrukturer og variabler i denne meddelelse. Så længe denne ensartethed bevares, kan en API implementeres i kode såvel som i deklarative tilpasninger, f.eks. modulære automatisk startede (eller platformsbegivenhedsudløste) forløb eller endda forløbsskabeloner. Baser dine beslutninger på, hvad der skal defineres i kode kontra i forløb, ikke på API-implementering, men snarere på pakkevenlighed og testabilitet.

• Bevar din livscyklus og versionering enkel. Ligesom alle dele af applikationsudvikling har API'er en livscyklus: definer, opbyg, test, implementer og vedligehold (herunder tilbagetræk). Salesforce Platform-API'er frigiver flere versioner inden for et kalenderår på grund af platformens hurtige frigivelsescyklus. (Du kan læse mere om denne adfærd i Salesforce Arkitektur - Grundlæggende.) Dette betyder, at platforms-API'er har en temmelig kompleks livscyklus, da flere versioner af en bestemt API skal vedligeholdes og være tilgængelige for Salesforce-kunder. Dette niveau af kompleksitet er relevant for PaaS-anvendelsessituationer – men det er sandsynligvis unødvendig kompleksitet for dine platformsløsningsarkitekturer (se: Læselighed anti-mønstre). Fokuser på definition af et tydeligt formål for en API (f.eks. fejlhåndtering) og tydelige basisdefinitioner. Tilstræbe kun at have en version af hver API.

• Gør dine API'er synlige, tilgængelige og administrerbare. Dokumenter dine API'er, så potentielle forbrugere nemt kan finde tilgængelige API'er, der opretter forbindelse til dem. API'er skal fungere uden problemer som en del af et landskab af kapaciteter.

• Vær iterativ. Fokuser på at definere og implementere kun en intern API ad gangen. På den måde kan du fokusere på at gentage API-definitionen hurtigt, finde den rigtige formular til din en understøttede version og etablere bedste fremgangsmåder ud fra erfaring med implementering.

Listen over mønstre og anti-mønstre nedenfor viser, hvordan korrekt (og dårlig) API-styring ser ud i en Salesforce-løsning. Du kan bruge disse til at validere dine designs, før du opbygger, eller identificere områder i dit system, der skal omstruktureres.

Hvis du vil vide mere om de værktøjer, der er tilgængelige fra Salesforce for at hjælpe dig med at opbygge større interoperabilitet, kan du se Værktøjer, der er relevante for sammensætningsværktøjer.

Følgende tabel viser et udvalg af mønstre, der skal søges efter (eller opbygges) i din organisation, og anti-mønstre, der skal undgås eller målrettes for rettelse.

✨ Oplev flere mønstre til interoperabilitet i Pattern & Anti-Pattern Explorer.

Oprettelse af pakbarhed i en Salesforce-organisation betyder, at funktionalitet i organisationen kommer fra enheder, der kan udvikles og implementeres uafhængigt og pålideligt som pakker. Ideelt set defineres disse enheder som en type pakke af anden generation (enten en ulåst pakke eller en administreret pakke for ISV'er). Bemærk: Da veludviklede løsninger udelukkende bruger disse pakketyper, er førstegenerations administrerede pakker ikke dækket her.

Det er en ting at definere separationer af bekymringer og skabe funktionelle enheder i en Salesforce-organisation. Det er en anden ting at fjerne problemer og administrere afhængigheder tydeligt nok til at versionere disse enheder som pakkeobjekter. Opnåelse af dette niveau af stabilitet og metadataisolering kræver et væsentligt niveau af DevOps (og arkitektonisk) modenhed. Det sætter også fart på udviklingstiden, forbedrer appkonstruktøroplevelser og bringer forudsigelighed og kontrol til versioner og versionsstyring. Ikke alle organisationer vil kunne understøtte den infrastruktur, der kræves for at definere, vedligeholde og udvikle effektive pakker. Men det at opnå pakbarhed bør være det ultimative mål for næsten enhver Salesforce-organisation.

Du kan opbygge pakbarhed i dine Salesforce-løsninger ved at fokusere på løs tilknytning og afhængighedsstyring.

I et system med løs kobling er individuelle dele ikke tæt forbundet med hinanden. Mange af fordelene ved et system, der kan sammensættes, stammer fra løs kobling. I pakkesystemer vil opnåelse af løs tilknytning mellem pakker (og installation af organisationer) give dig mulighed for at have veldefinerede pakker og mere produktive udviklingscyklusser for teams, der arbejder med pakker.

På Salesforce Platform kan du opbygge pakker, der er tæt forbundet med en bestemt organisation. Denne funktionalitet er nyttig til at definere funktionelle enheder og eksperimentere med korrekt separation af bekymringer i din organisation, efterhånden som du skrider fremad i pakke modenhed. Hvis du vælger denne tilgang, vil du dog genkende få af fordelene ved virkelig pakkebare metadata, herunder kildestyret udvikling, muligheden for at bruge versionsstyring og artefaktstabilitet. I stedet vil du sandsynligvis fortsætte med at opleve ulemperne ved et tæt forbundet system, herunder:

• Enkeltpunkter af fejl, der forårsager afbrydelser og ydeevneproblemer
• Langsomme, uforudsigelige implementeringer
• Vanskelige, komplekse fejlfindings- og fejlfindingscyklusser
• Problemer med skala og ydeevne

Slutmålet for ethvert Salesforce-system, der kan pakkes, er løst tilknyttede pakker.

Overvej følgende, når du ser på adskillelse af dine Salesforce-metadata i effektive pakker:

• Hvad tilpasninger er data kontra metadata. Når det gælder pakbarhed, behandler Salesforce Platform data og metadata meget forskelligt. Det er vigtigt at forstå, hvilke funktioner i din organisation der er metadata eller data. Du kan ikke inkludere data i nogen pakkede enheder. Når du beslutter, hvor du skal begynde at abstrahere funktionalitet i en pakket enhed, skal dine teams beslutte, om tilpasninger, der er lagret som data, skal udelades fra pakken fuldstændigt eller omstruktureres til en metadatabaseret implementering.
• Hvordan emballagen påvirker team. En logistisk realitet i Salesforce-pakning er, at meget af arbejdet med at producere og frigive en pakkeversion kræver færdigheder med Salesforce CLI og/eller CI/CD-teknologier. Dette betyder, at tilpasninger af både lav kode og programmering kræver tid og opmærksomhed fra nogen, der kan arbejde med pakkerelateret DevOps-teknologi. Afhængig af hvordan dit team administrerer funktionslevering, kan pakkeindføring udgøre væsentlige nedsættelser eller blokeringer for forskellige teams på tværs af en organisation. Du skal identificere, om teams vil kunne administrere funktionslevering via pakning og oprette en plan for at håndtere eventuelle færdigheds- eller personalemangler. Løsninger kan inkludere ibrugtagning af parret programmering eller implementering af CI/CD-job for udviklingsmiljøer.
• Hvordan emballage vil ændre miljøstrategier. I en pakkestyret udviklingslivscyklus bør tidligt arbejde udføres i scratch-organisationer. Disse midlertidige kildestyrede udviklingsmiljøer tillader hurtigere, mere gentagne cyklusser. De understøtter også mere detaljerede miljøadgangskontroller for dine udviklingsteams og større isolation fra produktion. Jo flere afhængigheder dine pakker har på ikke-pakkede metadata eller data, der kun findes i et sandbox- eller produktionsmiljø, desto mindre sandsynligt er det, at teams faktisk vil kunne bruge scratch-organisationer. Du kan aktivere kildesporing i sandboxes for at tillade kildestyrede udviklingsmønstre i ikke-scratch-organisationsmiljøer – men dine udviklingsteam vil ikke drage fordel af scratch-organisationers hastighed og iterative hastighed.
• Hvordan pakkeversioner relaterer sig til versioner. Planlæg, hvor ofte og i hvilken fase af udviklingspakkeversionering skal ske. Pakkeversionsanmodninger er begrænset (pr. organisation) på en 24-timers rullende basis. Som en generel bedste fremgangsmåde skal du kun versionere en pakke, når du er sikker på, at ingen af pakkeindholdene skal ændres. Ideelt vil du klargøre pakkeversioner, når kvalitetssikringsprocesserne er fuldført. Tillad ikke, at udviklingsteams bruger succes eller fejl i pakkeoprettelsesanmodninger som "test" af, hvor godt de har defineret pakkebegrænsninger. Der er måder, hvorpå du kan gøre dette uden at forsøge at versionere en pakkeartikel.
• Hvad den ideelle sluttilstand skal understøtte. Den ideelle pakkestrategi tillader kontrollerede, stabile Salesforce-versioner, der kan udvikles og leveres hurtigt. Definition af for mange pakker i hele din organisation kan generere nye typer af kompleksiteter og flaskehalse for udviklingsteams. En overdrevent modulariseret organisation kan også medføre, at versioner bliver langsomme og vanskelige. Start med at opbygge og frigive nogle få versioner af en enkelt meningsfuld pakke. Aflede opfølgningspakker trinvist. Stop med at introducere pakker, når du har en versionskadence, der tjener din forretning godt. Refactor-pakker over tid, hvis forretningsbehov ændres eller produktkvaliteten falder. Den ideelle pakkesluttilstand er subjektiv.

Uanset hvordan du beslutter at definere dine pakker, vil du kun få en vellykket version af en løst koblet pakke gennem effektiv afhængighedsstyring.

Listen over mønstre og anti-mønstre nedenfor viser, hvordan korrekt (og dårlig) løs kobling ser ud for Salesforce-pakker. Du kan bruge disse til at validere dine designs, før du opbygger, eller identificere områder i dit system, der skal omstruktureres.

Hvis du vil vide mere om Salesforce-værktøjer, der kan hjælpe dig med at opbygge større pakkevenlighed, kan du se Værktøjer, der er relevante for sammensatte.

I konteksten af en Salesforce-løsning betyder afhængighedsstyring at identificere og strukturere relationer mellem metadataene i dine pakker og metadataene i de organisationer, som disse pakker skal installeres i. Afhængighedsstyring er en vigtig del af udvikling af stabile pakkeobjekter.

Afhængigheder kan være i modstrid med bestræbelser på at skabe perfekt adskilte, løst sammenkoblede funktionelle enheder. I en ideel tekniktilstand har et løst tilknyttet system ingen afhængigheder mellem enheder. I den virkelige verden er det dog ikke praktisk at fjerne alle afhængigheder.

Ofte kræver balancen mellem at gøre systemer læselige og at bruge forretningsvenlige funktionsenheder en afvejning i form af fuldstændig isolering på tværs af enhederne i et system. Mere pragmatisk skaber de kerneydelser, der leveres af Salesforce Platforms standardfunktioner, nøgleafhængigheder for enhver Salesforce-løsning. Mange indbyggede skalerbarheds-, ydeevne- og sikkerhedsfordele kommer fra, hvor dybt de er integreret i platformen. Når du designer Salesforce-løsninger, der kan pakkes, er det vigtigt at huske, at pakkeafhængigheder ikke er dårlige. Dårlig afhængighedsstyring er dårlig.

Effektiv afhængighedsstyring med Salesforce-pakning betyder, at udvikling og vedligeholdelsesteams kan:

• Introduktion til nye projekter hurtigere og med begrænset miljøadgang
• Udvikl og test hurtigt ændringer
• Forstå, hvordan kompleks funktionalitet skal leveres i mindre, specifikke forpligtelser
• Kontroller frigivelseskadencer, og reducer vinduer med systemvedligeholdelse/frigivelsessvigt
• Forudsigelig tilbagerulning af negative ændringer i ethvert miljø

Teknikkerne til afhængighedsstyring med Salesforce er ganske enkle:

• Brug meddelelser og eventering til at håndtere smarte overførsler af statsmæssige eller statløse oplysninger mellem komponenter.
• Brug tilpassede metadatatyper til at levere dynamiske kørselsoplysninger og til at understøtte afhængighedsinjiceringsmønstre.
• Få Apex-udviklere til at bruge abstrakte klasser eller virtuelle klasser.

I sidste ende skal du beslutte, hvilke designmønstre der er tilladte i din organisation på tværs af deklarativ og programmeringsmæssig udvikling. De vigtigste overvejelser (arkitektonisk) er at definere, hvor du ønsker at tilføje mere teknikkompleksitet for at have færre afhængigheder, og hvor du skal tolerere flere afhængigheder for at forenkle appkonstruktørarbejdsflows.

Når du opbygger afhængighedsstyringsstrategier i dine pakker, skal du overveje de to primære organisatoriske principper for pakkeenheder: vandret og lodret.

• Horizontale grænser. I vandrette paradigmer abstrakteres funktionalitet, der kan være nødvendig af mere end en pakke, til et vandret lag. Vandrette lag bliver derefter kilden til almindelig funktionalitet og fås adgang til via en erklæret afhængighed. Minimizering af overflødig funktionalitet på tværs af pakker foretrækkes frem for minimering af afhængigheder.
• Vertikale grænser. Lodrette paradigmer maksimerer isolering og løs tilknytning mellem dele af systemet. Delt funktionalitet er begrænset, og lignende arbejde kan blive vist på tværs af enheder. Afhængigheder er strengt begrænset for at maksimere isolering mellem pakkeenheder.

Bemærk, at dette ikke er en enten/eller beslutning. Du kan blande lodrette og vandrette paradigmer efter behov. Ofte er den hurtigste måde at starte med en pakke på at oprette vandrette servicelager. Efterhånden som skalaen og kompleksiteten af din pakkeindføring vokser, vil abstraktion af flere lodrette enheder hjælpe med at forenkle komplekse miljøopsætningsprocesser eller udviklerintroduktion.

Et system med to funktionelle enheder (A og B), kan f.eks. struktureres med pakkeafhængigheder, der er arrangeret i lodrette, vandrette og lodrette-vandrette hybridparadigmer.

Uanset hvilket pakkearrangeringsparadigme du vælger, er der nogle absolutte, du skal huske på:

• Dubletter ikke metadata på tværs af pakker. Metadata, der er nødvendige for mere end en pakke, skal abstraheres til en eller flere pakker, der er erklæret som afhængigheder.
• Gør brug af de indbyggede afhængigheder i Salesforce Platform-metadata. For appkonstruktører giver de indbyggede tjenester, der tilbydes af Salesforce Platform, en masse funktionalitet, der hurtigt kan konfigureres. Mange af disse tjenester har indbyggede afhængigheder, der gør det vanskeligt at abstrahere dem til funktionelle enheder på lavt niveau. For en given metadatatype skal du forstå, hvor den falder langs spektret af indbyggede afhængigheder, og bruge denne forståelse til at definere dine pakkeafhængighedskæder. Start ikke pakkeindføring ved at forsøge at gennemtvinge løs tilknytning til et stykke standardplatformsfunktionalitet med mange indbyggede afhængigheder. Den tilføjer kompleksitet (ikke værdi), når du når funktioner i højere rækkefølge. Det er også en anden måde at falde ind i standard vs. custom anti-mønstre. Pak metadata fra bunden (færst afhængigheder) op – og gentag dem over tid.
• Pas på afhængighedskæderne. Undgå at oprette pakkeafhængighedskæder, der kræver, at udviklere opdeler deres ændringer i mange forskellige pakker ad gangen.
• Tænk over, hvad der giver mening for kildekontrol. Der er to grundlæggende måder, hvorpå du kan administrere dine pakker i kildekontrol. Den første er en enkelt monorepo med pakker isoleret i mapper. Den anden er flere repos med pakker isoleret i deres egen repos. Der er kompleksiteter ved at administrere hver type kildestrategi på lang sigt. I forbindelse med udviklerintroduktion er lodrette grænser mere effektive i flere Repo-paradigmer. Vandrette grænser er mere forståelige i en monorepo. Igen kan du blande og matche strategier, efterhånden som din arkitektur modnes.

Listen over mønstre og anti-mønstre nedenfor viser, hvordan korrekt (og dårlig) afhængighedsstyring ser ud med Salesforce-pakker. Du kan bruge disse til at validere dine designs, før du opbygger, eller identificere områder i dit system, der skal omstruktureres.

Hvis du vil vide mere om Salesforce-værktøjer til afhængighedsstyring, kan du se Værktøjer, der er relevante for sammensatte.

Følgende tabel viser et udvalg af mønstre, der skal søges efter (eller opbygges) i din organisation, og anti-mønstre, der skal undgås eller målrettes for rettelse.

✨ Oplev flere mønstre til emballage i Pattern & Anti-Pattern Explorer.

Hjælp os med at holde Salesforce Well-Architected relevant for dig. Tag vores undersøgelse for at give feedback om dette indhold og fortæl os, hvad du gerne vil se som det næste.