Les om våre oppdateringsplaner heri.

Sammenslåbare løsninger justeres raskt og med større stabilitet. Et system som er utformet for å kunne komponeres, er bygd i meningsfylte enheter, eller byggeblokker, som kan fungere elegant med hverandre og enkelt kan byttes inn og ut av service. Ved å bygge komponerbarhet i et system kan du introdusere nye funksjoner eller fjerne teknisk gjeld ved å omorganisere eller sette sammen individuelle enheter i et system. Sammensetning muliggjør raskere og mer forutsigbare leveringssykluser og -utgivelser fordi team kan fokusere på å bygge og levere meningsfylte funksjoner via mindre endringer.

Sammenslåbare systemer gjør det mulig for virksomheter å tilpasse seg raskere og med større stabilitet – enten stimulansen er intern for virksomheten eller forårsaket av eksterne faktorer. Sammenslåbarhet bidrar til at systemer blir mer resiliente og kan bidra til å gjøre løsninger og arkitektoniske mønstre mer hensiktsmessige.

Du kan gjøre Salesforce-løsninger mer komposterbare ved å bygge tre viktige vaner: adskillelse av bekymringer, interoperabilitet og pakking. Nedenfor kan du se relasjonen til disse vanene på to måter: for en enkelt enhet i et sammensatt system og på tvers av flere enheter i et sammensatt system.

En enkelt, sammensettbar enhet:

Et sammensettbart system:

En grunnleggende konsept i programvareutvikling og systemarkitektur, innebærer separasjon av bekymringer å identifisere ulike bekymringer innenfor et større system som kan deles inn i modulære enheter. Å oppnå en sterk adskillelse av bekymringer i et system krever opprettelse av meningsfylte enheter for programlogikk og funksjoner i hele systemet. Små enheter gjør det enklere for appleverings- og vedlikeholdsteam å forstå hvordan og hvor endringer skal utføres, med minimal avbrudd i det større systemet. Små enheter gjør det også tydeligere hvordan og hvor du skal fokusere arbeidet når du håndterer teknisk gjeld og bidrar til den generelle lesbarheten av systemet.

Du kan bygge bedre adskillelse av bekymringer i Salesforce-organisasjonen ved å orientere deg om forretningskapasitet og behandlingsstatus.

For Salesforce-systemer bruker den beste tilnærmingen for adskillelse av bekymringer et forretningsorientert perspektiv til å identifisere og organisere modulære enheter (eller funksjoner) i systemet. Dette er forskjellig fra en teknisk fokusert visning, som identifiserer enheter basert på deres tekniske funksjon. Et forretningsorientert perspektiv i adskillelse av bekymringer krever å organisere koden og tilpassingene i systemet basert på tjenesten de gir til forretnings- og forretningsbrukerne. Å ta denne løsningen betyr ikke å ignorere potensialet for overflødige eller duplikate tekniske funksjoner i et system. Det betyr heller at tekniske tjenester er tydelig tilordnet til et organisasjonsprinsipp som til syvende og sist er gjennomsiktig for virksomheten.

Å orientere seg om forretningsfunksjonalitet bidrar til å sikre at overføringene mellom forretningsanalyse og oppdagelsesteam til leveringsteam er så enkle som mulig. Hvis appbyggerne ikke har noen anelse om hvor arbeidsenhetene deres tilordnes til den samsvarbare arkitekturen, har du et rot, ikke et samsvarbart applandskap. Uklare tilordninger mellom sluttstatusen som kreves av virksomheten, og de modulære enhetene i en organisasjon, øker også sjansene for at utviklingsteam eller leverandører bygger overflødige funksjoner i systemet.

Vurder følgende for å orientere funksjonelle enheter til forretningskapasitet:

• Begynn med jobber som skal gjøres. Fokuser på jobbene som skal gjøres (JTBD) for brukere og selve virksomheten. JTBD-tilnærmingen, som ble startet av Tony Ulwick, fokuserer på å forstå "jobben", eller det sanne formålet, som personer prøver å oppnå ved å bruke et produkt eller en tjeneste. Det er et høyere abstraksjonsnivå enn brukernes rollerelaterte oppgaver eller de individuelle trinnene i en forretningsprosess. Oppgaver som duplikatkontroller og adressevalideringer kan for eksempel falle inn i en høyere rekkefølgefunksjon av å etablere en enkelt visning av kunden. Når du har en klar forståelse av disse forretningsfunksjonene av høyere orden, kan du begynne å tilordne deler av systemet til dem.
• Orienter til evner, ikke rapporteringsstrukturer. Det interne hierarkiet i forretningsenhetene er ikke en proxyer for meningsfylte funksjoner eller jobber som skal utføres. Det interne hierarkiet i virksomheten har en betydelig innvirkning på prosesser og teamstrukturer (for ikke å nevne budsjetter). Det er viktige logistiske vurderinger. Men virksomhetens funksjonelle behov opererer på et høyere nivå av abstraksjon enn logistikken. Hvis du oppretter en modul for å betjene en rapporteringsstruktur i stedet for en funksjon av høyere orden, må du være oppmerksom på at du kanskje må utføre flere trinn for å identifisere hvordan denne modulen er relatert til forretningsmuligheter.
• Vær gjentagende. Start med å samarbeide med virksomheten for å identifisere hvilken funksjonalitet som kan fungere for et minimum av levedyktig produkt (MVP). Når du har identifisert en funksjonalitet, begynner du å bygge denne MVP-en. Når du bygger, identifiserer du prosessene, metadataene og hendelsene eller meldingene som er sentrale for den funksjonelle enheten du oppretter. Identifiser eventuelle prosesser, metadata og hendelser eller meldinger som er eksterne avhengigheter. Etter hvert som mer funksjonelle enheter er utformet, implementerer du API-behandling og avhengighetsbehandling for å bygge enheter som fungerer godt med hverandre (i stedet for å bygge isolerte enheter).

Listen over mønstre og motmønstre nedenfor viser hvordan riktig (og dårlig) orientering til forretningsfunksjon ser ut i en Salesforce-løsning. Du kan bruke disse til å validere utformingene før du bygger, eller identifisere områder i systemet som må omformuleres.

Hvis du vil vite mer om verktøyene som er tilgjengelige fra Salesforce for å hjelpe deg med å orientere deg bedre i forretningsmuligheter, kan du se Verktøy som er relevante for sammensatt.

Statlig ledelse fokuserer på bevegelse av informasjon i et system på ulike tidspunkter. Effektiv tilstandsbehandling gir programmer mulighet til å håndtere komplekse dataflyter eller interaksjoner med et minimum av ikke-planlagte eller ubestemte utfall. Behandling av status i en modulær Salesforce-organisasjon betyr å bygge tydelige baner for logikkflyter innenfor og mellom enheter, i tillegg til gode baner for ikke-planlagte utførelsesvirkemåter. Statbehandling gjør det mulig å danne sammenhengende strømmer av logikk fra modulære Salesforce-programenheter. I de fleste tilfeller krever dette interoperabilitet for å strukturere informasjonsflyten mellom enheter.

Vanskeligheter med å behandle status på tvers av løst koblede enheter fører ofte til monolittisk programutvikling i Salesforce. Du kan se dette i store "monoflyter", som er bygd i et forsøk på å orkestrere en kompleks prosess i en entallsflyt. Et annet eksempel er massive Apex-klasser, som orkestrerer komplekse prosesser gjennom spaghetti-kode, eller en lang rekke engangsmetoder. Disse typene programarkitekturer gjør refaktoring og feilsøking vanskelig og øker introduksjonstidene for nye teammedlemmer eller leverandører. De reduserer også verdien av programmene som leveres til virksomheten, fordi funksjonalitet ikke kan brukes på nytt.

Vurder følgende for å behandle status på tvers av en modulær Salesforce-organisasjon:

• Bestem når du skal bruke mønstre med stat eller uten stat. Mønstre med status beholder informasjon i løpet av en utførelsesbane, ikke mønstre uten status. I et løst koblet system gjør statusløse mønstre det mulig å refaktorere komponenter raskere og med færre bivirkninger. Mønstre uten status er imidlertid ikke egnet for alle brukstilfeller. Hvis du bygger komponenter for dataoperasjoner, kan mønstre med status bidra til dataintegritet og konsistens i systemene. Bruk et mønster med status hvis komponenten oppfyller ett av følgende kriterier:
  • Bevissthet om plassering innenfor en større utførelsesbane er viktig for komponentens virkemåte
  • Virkemåten til komponenten må endres basert på resultatet av en nedstrøms handling (for eksempel må den endre utførelsen basert på meldinger om tilbakestilling/feil/suksess fra nedstrøms komponenter)
  • Komponenten må vente på svar fra et eksternt eller nedstrøms system for å fullføre arbeidet
• Opprett meningsfylte kategorier for statlig informasjon. Staten er en tvetydig term som kan brukes på en så dyp og bred rekke informasjon i (og utenfor) en Salesforce-organisasjon at selve termen er nesten meningsløs. Et nødvendig første trinn for å bygge tilstandsmønstre er derfor å opprette betydningsfulle kategorier for de viktigste tilstandsutførelsesbanene (eller typer tilstandsvirkemåter) i systemet. Noen kategorier å vurdere:
  • Navigering og skjemaer
  • Databaseoperasjoner
  • Gruppe- og gruppebehandlinger
  • Feil
• Definere datarelaterte statuser i form av databasetransaksjoner. Den innebygde virkemåten til plattformen vil omskrive de fleste viktige punktene om status for data i Salesforce. Ikke prøv å håndtere eller omgå denne virkemåten. Utform for og med den. Utform løsninger som minimerer, eller eliminerer, distribuert transaksjonslogikk. (Se databehandling for flere detaljer).
• Identifiser statuser som skjer innenfor (og på tvers av) funksjonelle enheter. Når du setter sammen funksjonelle enheter i større systemer, må du være oppmerksom på når du blander virkemåte for komponenter uten status og med status, og unngå kombinasjoner som kan skape endeløse sløyfer eller hull i behandling.
• Finn utleveringer. Vurder hvilke meldingsmønstre komponentene skal bruke til å overføre statusrelaterte data til en annen del av systemet. Sørg for at du bygger transaksjonsbevissthet og håndtering av komponentene. Ikke inkluder noen distribuert transaksjonslogikk i videresendingene.
• Opprett tilordninger mellom prosessdiagrammene og statusene. Prosessdiagrammer beskriver trinnene som flytter informasjon gjennom systemet på forskjellige tidspunkter. Et statusdiagram viser de faktiske endringene i informasjonen (statusen). Bruk bunntekstdelen for metadata i Salesforce-diagrammer til å fange opp den endrede tilstanden til informasjonen i hvert trinn i prosessen. Hvis du skiller prosessdiagrammer og statusdiagrammer, må du passe på å koble dem sammen. Dette konseptet bør ikke forveksles med å fange opp gjeldende og fremtidig status for prosesser eller systemlandskap under utforming og implementering, da det ikke gjelder informasjonen som beveger seg gjennom systemet.

Listen over mønstre og motmønstre nedenfor viser hvordan riktig (og dårlig) tilstandsbehandling ser ut i en Salesforce-løsning. Du kan bruke disse til å validere utforminger før du bygger, eller identifisere steder i systemet som må gjengis på nytt.

Hvis du vil vite mer om Salesforce-verktøy for behandling av status, kan du se Verktøy som er relevante for utforming.

Tabellen nedenfor viser et utvalg av mønstre som det skal søkes etter (eller bygges opp) i organisasjonen, og motmønstre som det skal unngås eller rettes opp mot.

✨ Oppdag flere mønstre for adskillelse av bekymringer i Mønsterutforsker.

I et system som er utformet for interoperabilitet, kan komponenter utveksle informasjon og fungere effektivt sammen. Interoperabilitet er nøkkelen til å gjøre et modulært system sammensatt i stedet for isolert. Interoperabilitet kan være vanskelig å oppnå i et løst koblet system. Du må etablere standarder for konsistente integrasjonsmetoder som ikke undergraver uavhengigheten mellom enhetene og den generelle separasjonen av bekymringer over hele systemet.

Interoperabilitet påvirker også kvaliteten på brukeropplevelsene. Brukerne forventer at data som er opprettet i ett område (som bestillingsinformasjon), kan brukes i et annet (som markedsføringskampanjer), og byggere forventer at hvis de lærer å gjøre noe (som å bygge en flyt eller godkjenne til et API), vil de finne kjente teknikker som fungerer når de går videre til neste problem. Mislykkede utforminger for interoperabilitet fører til overflødige arkitekturer, replikerte data, ineffektiv prosess og økte utvikling- og kundestøttekostnader.

Du kan opprette interoperabilitet i modulære systemer med meldinger og hendelser i tillegg til API-behandling.

Meldinger og hendelser er to måter du kan aktivere komponenter på tvers av et system for å sende og motta informasjon på. Når det gjelder innholdet de kan bære, er hendelser og meldinger like. En viktig forskjell er virkemåten til avsenderen. En komponent som sender en melding, sender vanligvis data til et bestemt mål og venter på en eller annen respons fra mottakeren. I motsetning til dette sender en komponent en hendelse når noe har skjedd. Det er ikke noe bestemt mål eller forventning om et svar. Disse forskjellene i virkemåte støtter forskjellige kommunikasjonsmønstre. Meldinger støtter kommunikasjonsmønstre med status, og hendelser støtter kommunikasjonsmønstre uten status. (Se Statsforvaltning for mer om denne forskjellen.)

Det er viktig å justere team for protokoller og bruke saker til meldinger og hendelser. Uklare standarder kan føre til en blanding av mønstre på tvers av systemet, noe som fører til følgende:

• Problemer med ytelse og skalerbarhet der feil mønstre brukes på et bestemt bruksområde
• Inkonsistent behandling som gjør at systemet virker ustabilt for sluttbrukere
• Lengre feilsøkingstider og mer komplekse vedlikeholdsprosesser

Vurder følgende når du utformer meldinger og hendelser for å opprette mer løst koblede strukturer i Salesforce-organisasjonen:

• Identifisere synkroniserings- og asynkroniseringsbrukstilfeller. Hendelse tillater løs koblet, statløs og asynkron kommunikasjon på tvers av et system. Meldinger tillater mer sterkt kontrollerte, statusrike og synkrone mønstre for kommunikasjon. Når du bestemmer når du skal bruke meldinger eller hendelser, må du bestemme om kommunikasjonen må være synkron (og potensielt blokkere) i forhold til asynkron og ikke-blokkert.
• Definer datastrukturer nøye. Strukturen til informasjonen som komponenter overfører mellom seg, er en viktig del av å holde et løst koblet system administrerbart og sammenhengende. (Se API Management for å finne ut mer om dette.) En viktig vurdering når du utformer en melding eller hendelse, er hvor ofte strukturen til informasjonen kan måtte endres. Når en meldings- eller hendelsesstruktur er definert og implementert i systemet, kan det være vanskelig å håndtere oppdateringer – spesielt hvis hendelsen eller meldingen allerede brukes til å sende informasjon til et eksternt system.
• Riktig store meldinger. Generelt sett er det en god fremgangsmåte å holde meldingsstørrelser små. Det er imidlertid også en balansehandling mellom meldings størrelse og meldings volum. Systemer kan behandle mindre mengder data raskere. Handlingen med behandling kommer med en mengde ekstra overskudd fordi mottakere må pakke ut, tolke og bestemme hva de skal gjøre med informasjon de har mottatt. Disse trinnene kan ta en ubetydelig tid å fullføre, men de kan bygge opp og skape en belastning på systemer i stor skala. Unngå utforminger som krever at komponenter i systemet behandler mange små meldinger i rekkefølge for å fullføre en bit arbeid. For å få den riktige størrelsen på meldingene dine bør du tenke på å utforme det minste antall nedstrøms datakomponenter som må behandles og behandles på informasjonen de har blitt sendt, uten også å anta at hver nedstrøms komponent kan be om eller behandle en rekke oppfølgingsmeldinger.
• Design for skalerbarhet. Løselig koblede komponenter kan gjøre det enklere å skalere arkitekturen. Ved å eliminere avhengigheter på tvers av komponenter kan team arbeide med å forbedre ytelsen eller skalerbarheten til en hvilken som helst individuell komponent med minimale effekter på de andre. Men løst koblede komponenter innebærer også betydelig kompleksitet i arkitekturen i stor skala (spesielt når det gjelder behandlingstilstand). Identifiser prosesser som trenger mer tett koblet logikk eller avhengigheter av gyldige brukeropplevelses- eller dataintegritetsårsaker, og ikke forsøk å introdusere asynkrone/hendelsesbaserte mønstre i disse prosessene. Bruk i stedet synkroniserings- og meldingsbaserte mønstre og riktig feilhåndtering.

Listen over mønstre og motmønstre nedenfor viser hvordan riktige (og dårlige) meldinger og hendelser ser ut i en Salesforce-løsning. Du kan bruke disse til å validere utforminger før du bygger, eller identifisere steder i systemet som må gjengis på nytt.

Hvis du vil vite mer om Salesforce-meldinger og hendelsesverktøy, kan du se Verktøy som er relevante for sammensatt. Hvis du vil vite mer om hvordan du velger et oppstillingsmønster eller et verktøy for et gitt bruksområde, kan du se Arkitektveiledningen for hendelsesdrevet arkitektur med Salesforce.

Ved å bygge riktig API-behandling (programmeringsgrensesnitt) i en Salesforce-løsning kan individuelle komponenter i systemet følge forutsigbare kommunikasjonsmønstre. Salesforce har innebygde, sikre API-er som kan brukes til kommunikasjon med systemer utenfor Salesforce. (Se Grunnleggende om arkitektur for å få mer informasjon om Salesforce Platform APIer.)

Effektiv API-behandling i Salesforce-løsninger er nøkkelen til å bygge arkitekturer som virkelig kan komponeres. Den gir komponenter i en Salesforce-organisasjon mulighet til å sende og motta informasjon effektivt. Den gir også løsningsbyggere mulighet til å følge tydelige protokoller for hvordan komponentene de bygger, kommuniserer med andre komponenter i systemet, og hjelper dem med å identifisere dårlige implementeringer tidlig. Videre gir den løsningskonstruktører mulighet til å fokusere mer begrenset på den bestemte komponenten de bygger eller omformer, noe som øker produktiviteten og kvaliteten.

API-behandling på bedriftsnivå er et eget emne – og oppnås best med et omfattende API-behandlingsverktøy. (Se Hva er API Management? for å få mer informasjon om MuleSoft-perspektivet om dette emnet.)

Vurder følgende for å bygge API-behandlingsfunksjonalitet i Salesforce-løsningene:

• Tenk på API-er som forutsigbare mønstre eller kontrakter for kommunikasjon. Datatypen for inndata- eller utdatavariabler, variabelnavnene, bitene med informasjon som skal (eller ikke skal) vises i et gitt mønster – disse er nøklene til effektiv API-behandling. Disse definisjonene bør vises i utformingsstandardene, og team bør kunne finne ut hvordan disse definisjonene har blitt implementert i bestemte deler av systemet via dokumentasjonen. En måte å se problemer med å slå sammen endringer fra ny utvikling til et integrasjonsmiljø på, er å se på dem som bevis på hvor du har dårlig implementert API-kommunikasjon (eller kanskje ingen API-definisjon i det hele tatt).

• Ikke begrens tankegangen din om API-er til å kode eksklusivt. Det som definerer en API i denne konteksten, er konsistensen av meldingsstrukturene og -variablene i denne meldingen. Så lenge denne konsistensen beholdes, kan et API implementeres i kode så vel som i deklarative tilpassinger, som modulære automatisk startede (eller plattformhendelsesutløste) flyter eller til og med flytmaler. Baser beslutningene dine på hva som skal defineres i kode kontra i flyter, ikke på API-implementering, men på pakkingsmulighet og testabilitet.

• Hold livssyklusen og versjonsbehandling enkel. Som alle deler av programutvikling har API-er en livssyklus: definere, bygge, teste, distribuere og vedlikeholde (inkludert tilbaketrekking). Salesforce Platform API-er utgir flere versjoner innen et kalenderår på grunn av plattformens raske utgivelsessyklus. (Du kan lese mer om denne virkemåten i Salesforce Arkitektur Grunnleggende.) Det betyr at plattform-API-er har en ganske kompleks livssyklus fordi flere versjoner av en bestemt API må vedlikeholdes og være tilgjengelig for Salesforce-kunder. Dette nivået av kompleksitet passer for PaaS-brukstilfeller – men det er mest sannsynlig unødvendig kompleksitet for dine plattformløsningsarkitekturer (se: Readablility anti-mønstre). Fokuser på å definere et klart formål for en API (for eksempel feilhåndtering) og klare definisjoner av standarden. Mål å ha bare én versjon av hvert API.

• Gjør API-ene oppdagbare, tilgjengelige og administrerbare. Dokumenter API-ene slik at potensielle forbrukere enkelt kan finne tilgjengelige API-er som kobler til dem. API-er må fungere problemfritt som en del av et funksjonslandskap.

• Vær gjentagende. Fokuser på å definere og implementere bare én intern API om gangen. På den måten kan du fokusere på å gjenta API-definisjonen raskt, finne riktig skjema for din én støttede versjon og etablere gode fremgangsmåter fra opplevelsen av implementering.

Listen over mønstre og motmønstre nedenfor viser hvordan riktig (og dårlig) API-behandling ser ut i en Salesforce-løsning. Du kan bruke disse til å validere utformingene før du bygger, eller identifisere områder i systemet som må omformuleres.

Hvis du vil vite mer om verktøy som er tilgjengelig fra Salesforce for å hjelpe deg med å bygge mer interoperabilitet, kan du se Verktøy som er relevante for sammensettbarhet.

Tabellen nedenfor viser et utvalg av mønstre som det skal søkes etter (eller bygges opp) i organisasjonen, og motmønstre som det skal unngås eller rettes opp mot.

✨ Oppdag flere mønstre for interoperabilitet i Pattern & Anti-Pattern Explorer.

Opprettelse av pakkingsmulighet i en Salesforce-organisasjon betyr at funksjonalitet i organisasjonen kommer fra enheter som kan utvikles og distribueres uavhengig og pålitelig som pakker. Ideelt sett er disse enhetene definert som en type pakke av andre generasjon (enten en ulåst pakke eller administrert pakke for ISV-er). Notat: Fordi velbygde løsninger bruker disse pakketypene eksklusivt, dekkes ikke førstegenerasjons administrerte pakker her.

Det er én ting å definere oppdelinger og opprette funksjonelle enheter i en Salesforce-organisasjon. Det er en annen ting å løsne og behandle avhengigheter tydelig nok til å kunne versjonere disse enhetene som pakkeartefakter. Å oppnå dette nivået av stabilitet og metadataisolering krever et betydelig nivå av DevOps (og arkitektonisk) modenhet. Den øker også utviklingstiden, forbedrer appbyggeropplevelsene og gir forutsigbarhet og kontroll for utgivelses- og utgivelsesbehandling. Ikke alle organisasjoner vil kunne støtte infrastrukturen som kreves for å definere, vedlikeholde og utvikle effektive pakker. Men å oppnå pakkingsmulighet bør være det ultimate målet for nesten alle Salesforce-organisasjoner.

Du kan bygge pakkingsmuligheter i Salesforce-løsningene ved å fokusere på løs kobling og avhengighetsbehandling.

I et system med løs kobling er ikke individuelle biter sterkt knyttet til hverandre. Mange av fordelene med et sammensettbart system kommer fra løs kobling. I pakkebare systemer vil oppnåelse av løs kobling mellom pakker (og installering av organisasjoner) gi deg mulighet til å ha veldefinerte pakker og mer produktive utviklingssykluser for team som arbeider med pakker.

På Salesforce Platform kan du bygge pakker som er tett koblet til en bestemt organisasjon. Denne funksjonen er nyttig for å definere funksjonelle enheter og eksperimentere med riktig separasjon av bekymringer i organisasjonen, etter hvert som du går fremover i emballasje modenhet. Hvis du velger denne tilnærmingen, vil du imidlertid forstå noen få av fordelene med virkelig pakkebare metadata, inkludert kildedrevet utvikling, muligheten til å bruke versjonsbehandling og gjenstandsstabilitet. I stedet vil du sannsynligvis fortsatt oppleve ulempene med et sterkt koblet system, inkludert:

• Enkelte feilpunkter som fører til avbrudd og ytelsesproblemer
• Langsomme, uforutsigbare distribusjoner
• Vanskelige, komplekse feilsøkings- og feilsøkingssykluser
• Problemer med skala og ytelse

Sluttmålet for eventuelle pakkebare Salesforce-systemer er løst koblede pakker.

Vurder følgende når du ser på å skille Salesforce-metadataene i effektive pakker:

• Hva tilpasninger er data kontra metadata. Når det gjelder pakking, behandler Salesforce Platform data og metadata veldig forskjellig. Det er viktig å forstå hvilke funksjoner i organisasjonen som er metadata eller data. Du kan ikke inkludere data i noen pakkede enheter. Etter hvert som du bestemmer hvor du skal begynne å abstrahere funksjonalitet til en pakket enhet, må teamene dine bestemme om tilpassinger som er lagret som data, skal utelukkes fra pakken helt eller omformuleres til en metadatabasert implementering.
• Hvordan emballasje påvirker team. En logistisk realitet for Salesforce-pakker er at mye av arbeidet med å produsere og utgi en pakkeversjon krever ferdigheter med Salesforce CLI og/eller CI/CD-teknologier. Det betyr at tilpassinger med lite kode og programmatisk tilpassing på samme måte vil kreve tid og oppmerksomhet fra noen som er i stand til å arbeide med pakkerelatert DevOps-teknologi. Avhengig av hvordan teamet ditt administrerer funksjonslevering, kan pakketilpassing føre til betydelige nedganger eller blokkeringer for forskjellige team på tvers av en organisasjon. Du må identifisere om teamene skal kunne administrere funksjonslevering via pakking, og lage en plan for å løse eventuelle kvalifikasjons- eller personalgap. Løsninger kan inkludere å ta i bruk paret programmering eller implementere CI/CD-jobber for utviklingsmiljøer.
• Hvordan emballasje vil endre miljøstrategier. I en pakkedrevet utviklingslivssyklus bør tidlig arbeid gjøres i snarveierorganisasjoner. Disse midlertidige, kildedrevne utviklingsmiljøene tillater raskere, mer gjentagende sykluser. De støtter også mer detaljerte miljøtilgangskontroller for utviklingsteamene og større isolasjon fra produksjon. Jo flere avhengigheter pakkene har på ikke-pakkede metadata eller data som bare finnes i et Sandbox- eller produksjonsmiljø, desto mindre sannsynlig er det at team faktisk kan bruke midlertidige organisasjoner. Du kan aktivere kildesporing i Sandbox-organisasjoner for å tillate kildedrevne utviklingsmønstre i ikke-kodede organisasjonsmiljøer, men utviklingsteamene dine vil ikke dra nytte av hastigheten og den gjentagende hastigheten til midlertidige organisasjoner.
• Hvordan pakkeversjoner er relatert til utgivelser. Planlegg hvor ofte og i hvilken fase versjonsbehandling av utviklingspakken skal skje. Pakkeversjonsforespørsler er begrenset (per organisasjon) på rullerende basis på 24 timer. En god generell fremgangsmåte er å bare versjonere en pakke når du er sikker på at ingen av pakkeinnholdet trenger å endres. Ideelt sett vil du klargjøre pakkeversjoner etter at kvalitetssikringsprosesser er fullført. Ikke la utviklingsteam bruke vellykket eller mislykket opprettelse av pakkeforespørsler som "tester" på hvor godt de har definert pakkebegrensene. Det finnes måter å gjøre dette på uten å forsøke å versjonere et pakkeartefaktum.
• Hva den ideelle sluttstat skal støtte. Den ideelle pakkestrategien tillater kontrollerte, stabile Salesforce-utgivelser som kan utvikles og leveres raskt. Å definere for mange pakker i hele organisasjonen kan generere nye typer kompleksitet og flaskehalser for utviklingsteam. En overdrevent modulær organisasjon kan også føre til at utgivelser blir trege og vanskelige. Start med å bygge og utgi noen få versjoner av en enkelt, meningsfylt pakke. Utled oppfølgingspakker trinnvis. Slutt å introdusere pakker når du har en utgivelseskadens som betjener virksomheten godt. Refactor-pakker over tid, hvis forretningsbehovene endres eller utgivelseskvaliteten avtar. Den ideelle pakkesluttstatusen er subjektiv.

Uansett hvordan du bestemmer deg for å definere pakkene, vil du bare kunne få en vellykket versjon av en løst koblet pakke gjennom effektiv avhengighetsbehandling.

Listen over mønstre og anti-mønstre nedenfor viser hvordan riktig (og dårlig) løs kobling ser ut for Salesforce-pakker. Du kan bruke disse til å validere utformingene før du bygger, eller identifisere områder i systemet som må omformuleres.

Hvis du vil vite mer om Salesforce-verktøy som hjelper deg med å bygge mer pakkbarhet, kan du se Verktøy som er relevante for sammensettbarhet.

I sammenheng med en Salesforce-løsning betyr avhengighetsbehandling å identifisere og strukturere relasjonene mellom metadataene i pakkene og metadataene i organisasjonene som disse pakkene skal installeres i. Avhengighetsbehandling er en viktig del av utvikling av stabile pakkeartefakter.

Avhengigheter kan være i motsetning til innsatsen for å skape perfekt adskilte, løst koblede funksjonelle enheter. I en ideell teknisk tilstand har et løst koblet system ingen avhengigheter mellom enheter. I den virkelige verden er det imidlertid ikke praktisk å eliminere alle avhengigheter.

Ofte krever balansen mellom å gjøre systemer lesbare og å bruke forretningsvennlige funksjonelle enheter en kompromiss i form av perfekt isolasjon på tvers av enhetene i et system. På en mer pragmatisk måte skaper kjerntjenestene som tilbys av Salesforce Platforms standardfunksjonalitet, viktige, netto-positive avhengigheter for alle Salesforce-løsninger. Mange fordeler med innebygd skalerbarhet, ytelse og sikkerhet kommer fra hvor dypt de er integrert i plattformen. Når du utformer pakkebare Salesforce-løsninger, er det viktig å huske at pakkeavhengigheter ikke er iboende dårlige. Dårlig avhengighetsbehandling er dårlig.

Effektiv avhengighetsbehandling med Salesforce-pakker betyr at utvikling- og vedlikeholdsteam kan

• Introduksjon til nye prosjekter raskere og med begrenset tilgang til miljøet
• utvikle og teste endringer raskt
• Forstå hvordan kompleks funksjonalitet skal leveres i mindre, spesifikke forpliktelser
• Kontrollere utgivelseskadenser og redusere vinduer med systemvedlikehold/utgivelsesavbrudd
• Forutsigbart tilbakevendende negative endringer i et hvilket som helst miljø

Teknikkene for avhengighetsbehandling med Salesforce er ganske enkle:

• Bruk meldinger og gjennomganger til å håndtere smarte overføringer av informasjon med eller uten status mellom komponenter.
• Bruk tilpassede metadatatyper til å gi dynamisk kjøretidsinformasjon og støtte innsettingsmønstre for avhengigheter.
• La Apex-utviklere bruke abstrakte eller virtuelle klasser.

Til slutt må du bestemme utformingsmønstrene som er tillatt i organisasjonen, på tvers av deklarativ og programmatisk utvikling. De viktigste punktene (arkitektonisk) er å definere hvor du vil legge til mer teknisk kompleksitet for å få færre avhengigheter, og hvor du må tolerere flere avhengigheter for å forenkle appbyggerarbeidsflyter.

Når du bygger avhengighetsbehandlingsstrategier i pakkene, bør du vurdere de to primære organisasjonsprinsippene for pakkenheter: horisontal og vertikal.

• Horisontale grenser. I horisontale paradigmer abstrakteres funksjonalitet som kan være nødvendig for flere pakker, til et horisontalt lag. Horisontale lag blir da kilden til felles funksjonalitet og får tilgang via en erklært avhengighet. Minimering av overflødig funksjonalitet på tvers av pakker foretrekkes fremfor minimering av avhengigheter.
• Vertikale grenser. Vertikale paradigmer maksimerer isolasjon og løs kobling mellom deler av systemet. Delt funksjonalitet er begrenset, og lignende arbeid kan vises på tvers av enheter. Avhengigheter er strengt begrenset for å maksimere isolasjon mellom pakkenheter.

Vær oppmerksom på at dette ikke er en av dem. Du kan blande vertikale og horisontale paradigmer etter behov. Ofte er den raskeste måten å starte med en pakke på å opprette horisontale tjenestelager. Etter hvert som omfanget og kompleksiteten av pakketilpassingen øker, vil abstraksjon av flere vertikale enheter bidra til å forenkle komplekse miljøoppsettprosesser eller introduksjon av utviklere.

Et system med to funksjonelle enheter (A og B), for eksempel, kan struktureres med pakkeavhengigheter ordnet i vertikale, horisontale og vertikal-horisontale hybridparadigmer.

Uavhengig av pakkeorganisasjonsparadigmet du velger, er det noen absolutte du bør være oppmerksom på:

• Ikke dupliser metadata på tvers av pakker. Metadata som kreves av flere enn én pakke, skal abstraheres til én eller flere pakker som er erklært som avhengigheter.
• Bruk de innebygde avhengighetene i Salesforce Platform-metadata. For appbyggere gir de innebygde tjenestene som tilbys av Salesforce Platform, mye funksjonalitet som kan konfigureres raskt. Mange av disse tjenestene har innebygde avhengigheter som gjør det vanskelig å abstrakte dem til funksjonelle enheter på lavt nivå. For en gitt metadatatype må du forstå hvor den faller langs spekteret av innebygde avhengigheter, og bruke denne forståelsen til å definere pakkeavhengighetskjeder. Ikke start pakketilpassing ved å prøve å tvinge løs kobling til en bit standard plattformfunksjonalitet med mange innebygde avhengigheter. Det vil legge til kompleksitet (ikke verdi) etter hvert som du når funksjonalitet av høyere orden. Det er også en annen måte å falle inn i standard vs tilpasset anti-mønstre. Pakk metadata fra bunnen (færrest avhengigheter) opp – og gjentak over tid.
• Se opp for avhengighetskjeden. Unngå å opprette pakkeavhengighetskjeder som vil kreve at utviklere deler opp endringene sine i mange forskjellige pakker samtidig.
• Tenk på hva som er fornuftig for kildekontroll. Det finnes to grunnleggende måter å behandle pakkene på i kildekontroll. Den første er en enkelt monorepo med pakker isolert i mapper. Den andre er flere repos med pakker isolert i sin egen repos. Det er kompleksitet ved behandling av hver type kildestrategi på lang sikt. Når det gjelder introduksjon av utviklere, er vertikale grenser mer effektive i flere representasjonsparadigmer. Horisontale grenser er mer forståelige i et monorepo. Igjen kan du blande og samsvare strategier etter hvert som arkitekturen modnes.

Listen over mønstre og motmønstre nedenfor viser hvordan riktig (og dårlig) avhengighetsbehandling ser ut med Salesforce-pakker. Du kan bruke disse til å validere utformingene før du bygger, eller identifisere områder i systemet som må omformuleres.

Hvis du vil vite mer om Salesforce-verktøy for avhengighetsbehandling, kan du se Verktøy som er relevante for sammensatt.

Tabellen nedenfor viser et utvalg av mønstre som det skal søkes etter (eller bygges opp) i organisasjonen, og motmønstre som det skal unngås eller rettes opp mot.

✨ Oppdag flere mønstre for pakking i Pattern & Anti-Pattern Explorer.

Hjelp oss å holde Salesforce Well-Architected relevant for deg, ta vår undersøkelse for å gi tilbakemelding om dette innholdet og fortell oss hva du vil se videre.