Läs om våra uppdateringsscheman här.

Komponerbara lösningar justeras snabbt och med större stabilitet. Ett system som är utformat för att vara komponerbart är byggt i meningsfulla enheter, eller byggstenar, som kan fungera smidigt med varandra och enkelt kan bytas in och ut. Att bygga in komponerbarhet i ett system låter dig introducera nya funktioner eller ta bort teknisk skuld genom att refaktorisera eller återsamla individuella enheter i ett system. Komponerbarhet möjliggör snabbare, mer förutsägbara leveranscykler och utgåvor, eftersom team kan fokusera på att bygga och leverera meningsfulla funktioner via mindre mängder ändringar.

Komponerbara system gör det möjligt för verksamheter att anpassa sig snabbare och med större stabilitet — oavsett om stimulansen är intern i verksamheten eller orsakad av externa faktorer. Komponerbarhet hjälper system att bli mer elastiska och kan hjälpa till att göra lösningar och arkitektoniska mönster mer avsiktliga.

Du kan göra dina Salesforce-lösningar mer sammansatta genom att bygga tre nyckelvanor: separation av problem, interoperabilitet och paketerbarhet. Nedan kan du se relationen mellan dessa vanor på två sätt: för en enskild enhet av i ett sammansatt system och över flera enheter i ett sammansatt system.

En enda, komponerbar enhet:

Ett sammansatt system:

Ett grundläggande koncept inom programvaruteknik och systemarkitektur, separation av problem innebär att identifiera olika problem inom ett större system som kan delas upp i modulära enheter. Att uppnå en stark separation av problem inom ett system kräver att meningsfulla enheter för programlogik och funktioner skapas i hela systemet. Mindre enheter gör det enklare för appleveranser och underhållsteam att förstå hur och var de ska göra ändringar, med minimal störning av det större systemet. Mindre enheter gör det även tydligare hur och var arbetet ska fokuseras när det gäller tekniska skulder och bidrar till systemets övergripande läsbarhet.

Du kan bygga in bättre separation av problem i din Salesforce-organisation genom att fokusera på verksamhetskapacitet och hantera status.

För Salesforce-system tillämpar den bästa metoden för att separera problem ett verksamhetsorienterat perspektiv för att identifiera och organisera modulära enheter (eller kapaciteter) inom systemet. Detta skiljer sig från en teknikfokuserad vy som identifierar enheter baserat på deras tekniska funktion. Ett verksamhetsorienterat perspektiv för att separera problem kräver att du organiserar koden och anpassningarna i ditt system baserat på den tjänst de tillhandahåller till affärs- och verksamhetsanvändarna. Detta innebär inte att man ignorerar potentialen för överflödiga eller duplicerade tekniska funktioner i ett system. Det innebär snarare att tekniska tjänster är tydligt mappade till en organisationsprincip som i slutändan är transparent för verksamheten.

Att orientera sig efter verksamhetskapacitet hjälper till att säkerställa att överföringarna mellan verksamhetsanalys och upptäckarteam till leveransteam är så enkla som möjligt. Om appbyggare inte har någon aning om var deras arbetsenheter mappar till din komponerbara arkitektur har du en enda röra, inte ett komponerbart applandskap. Otydliga mappningar mellan det slutläge som krävs av verksamheten och de modulära enheterna inom en organisation ökar också chansen för utvecklingsteam eller leverantörer att bygga överflödiga funktioner i systemet.

Tänk på följande för att orientera funktionella enheter till verksamhetskapacitet:

• Börja med jobb som ska utföras. Fokusera på de jobb som ska utföras (JTBD) för användare och själva verksamheten. Banbrytande av Tony Ulwick fokuserar JTBD-metoden på att förstå det "jobb", eller sanna syfte, som människor försöker uppnå genom att använda en produkt eller tjänst. Det är en högre abstraktionsnivå än användares rollrelaterade uppgifter eller de enskilda stegen i en verksamhetsprocess. Till exempel kan uppgifter som dubblettkontroller och adressvalideringar hamna i en högre ordningsfunktion som "upprätta en enskild vy av kunden". När du har en klar uppfattning om dessa affärsmöjligheter med högre order kan du börja mappa delar av ditt system till dem.
• Orientera till kapacitet, inte rapporteringsstrukturer. Den interna hierarkin för dina affärsenheter är inte en proxy för meningsfull kapacitet eller jobb som ska utföras. Den interna hierarkin i din verksamhet har en väsentlig påverkan på processer och teamstrukturer (för att inte tala om budgetar). Detta är viktiga logistiska överväganden. Men verksamhetens funktionella behov verkar på en högre abstraktionsnivå än logistik. Om du skapar en modul för att serva en rapporteringsstruktur istället för en funktion med högre ordning, var medveten om att du kan behöva vidta ytterligare steg för att identifiera hur modulen relaterar till verksamhetskapacitet.
• Var iterativ. Börja med att samarbeta med verksamheten för att identifiera vilken kapacitet som skulle kunna fungera för en minsta livskraftig produkt (MVP). När du har identifierat en kapacitet, börja bygga denna MVP. När du bygger, identifiera de processer, metadata och händelser eller meddelanden som är centrala för den funktionella enhet du skapar. Identifiera processer, metadata och händelser eller meddelanden som är externa beroenden. När fler funktionella enheter utformas, implementera API-hantering och beroendehantering för att bygga enheter som fungerar bra med varandra (istället för att bygga siloenheter).

Listan över mönster och antimönster nedan visar hur korrekt (och dålig) orientering till verksamhetsfunktioner ser ut i en Salesforce-lösning. Du kan använda dessa för att validera dina konstruktioner innan du bygger, eller identifiera områden i ditt system som behöver omfaktoriseras.

Mer information om de verktyg som är tillgängliga från Salesforce för att hjälpa dig att bättre orientera dig efter verksamhetskapacitet finns i Verktyg som är relevanta för komponerbara.

Delstatshantering fokuserar på förflyttning av information genom ett system vid olika tidpunkter. Effektiv lägeshantering låter program hantera komplexa flöden av data eller interaktioner med ett minimum av oplanerade eller obestämda resultat. Att hantera status i en modulär Salesforce-organisation innebär att bygga tydliga vägar för logikflöden inom och mellan enheter, samt eleganta vägar för oplanerade utförandebeteenden. Statushantering gör det möjligt att skapa sammanhängande strömmar av logik från modulära Salesforce-programenheter. I de flesta fall kräver detta interoperabilitet för att strukturera informationsflödet mellan enheter.

Svårigheter att hantera status för löst kopplade enheter leder ofta till monolitisk applikationsutveckling i Salesforce. Du kan se detta i stora "monoflöden", som är byggda i ett försök att orkestrera en komplex process inom ett singularflöde. Ett annat exempel är massiva Apex klasser, som orkestrerar komplexa processer genom spaghettikod, eller en lång serie engångsmetoder. Dessa typer av programarkitekturer gör det svårt att omfaktorisera och felsöka och ökar introduktionstider för nya teammedlemmar eller leverantörer. De minskar även värdet på de program som levereras till verksamheten, eftersom funktionalitet inte kan återanvändas.

Tänk på följande för att hantera status i en modulär Salesforce-organisation:

• Bestäm när du vill använda tillståndsbaserade jämfört med tillståndslösa mönster. Tillståndsmönster behåller information genom en utförandeväg, till skillnad från tillståndslösa mönster. I ett löst kopplat system gör tillståndslösa mönster det möjligt för komponenter att refaktoriseras snabbare och med färre biverkningar. Statuslösa mönster är dock inte lämpliga för alla användningsfall. Om du bygger komponenter för dataoperationer kan tillståndsmönster hjälpa till med dataintegritet och enhetlighet i alla dina system. Använd ett statusfyllt mönster om din komponent uppfyller något av följande kriterier:
  • Medvetenhet om placering inom en större utförandeväg är avgörande för komponentens beteende
  • Beteendet för komponenten måste ändras baserat på resultaten av en åtgärd längre ner (till exempel måste den ändra utförandet baserat på tillbakadragande/fel/framgångsmeddelanden från komponenter längre ner)
  • Komponenten måste vänta på svar från ett externt eller senare system för att slutföra sitt arbete
• Skapa meningsfulla kategorier för lägesinformation. State är en tvetydig term som kan tillämpas på en så djup och bred uppsättning information inom (och utanför) en Salesforce-organisation att termen i sig själv är nästan meningslös. Ett nödvändigt första steg för att bygga tillståndsmönster är därför att skapa meningsfulla kategorier för de viktigaste tillståndsberoende körningsvägarna (eller typerna av tillståndsberoende beteenden) i ditt system. Några kategorier att överväga:
  • Navigering och formulär
  • Databasoperationer
  • Batch- och massåtgärder
  • Fel
• Definiera datarelaterade lägen i form av databastransaktioner. Plattformens inbyggda beteenden kommer att begränsa majoriteten av övervägandena för data i Salesforce. Försök inte hantera mot eller runt detta beteende. Utforma för och med den. Utforma lösningar som minimerar eller eliminerar distribuerad transaktionslogik. (Se datahantering för mer information).
• Identifiera lägen som inträffar inom (och mellan) funktionella enheter. När du sätter samman funktionella enheter i större system, var medveten om när du blandar statuslöst och statuslöst komponentbeteende och förhindra kombinationer som kan skapa oändliga loopar eller luckor i bearbetningen.
• Definiera överlämningar. Tänk igenom vilka komponenter för meddelande- eller händelsemönster som kommer att användas för att överföra statusrelaterade data till en annan del av systemet. Se till att du bygger upp transaktionsmedvetenhet och hantering i dina komponenter. Inkludera inte någon distribuerad transaktionslogik i dina överlämningar.
• Skapa mappningar mellan dina processdiagram och lägen. Processdiagram beskriver de steg som flyttar information genom ditt system vid olika tidpunkter. Ett lägesdiagram visar de faktiska ändringarna i informationen (staten). Använd metadatasidfotdelen i formerna Salesforce-diagram för att samla in information som ändras i varje steg i processen. Om du separerar processdiagram och statusdiagram, se till att länka dem. Detta koncept ska inte blandas ihop med att samla in nuvarande och framtida status för processer eller systemlandskap under design och implementering, eftersom det inte handlar om att informationen rör sig genom systemet.

Listan över mönster och antimönster nedan visar hur korrekt (och dåligt) lägeshantering ser ut i en Salesforce-lösning. Du kan använda dessa för att validera dina konstruktioner innan du bygger, eller identifiera platser i ditt system som behöver omfaktoriseras.

Mer information om Salesforces verktyg för att hantera status finns i Verktyg relevanta för komponerbara.

Följande tabell visar ett urval av mönster att leta efter (eller bygga) i din organisation och antimönster att undvika eller rikta in sig på för att åtgärda.

✨ Upptäck fler mönster för separation av problem i Mönster & Anti-Mattern Explorer.

I ett system som utformats för interoperabilitet kan komponenter utbyta information och fungera tillsammans på ett effektivt sätt. Interoperabilitet är nyckeln till att göra ett modulärt system komponerbart snarare än siloat. Interoperabilitet kan vara svårt att uppnå i ett löst kopplat system. Du måste skapa standarder för enhetliga integreringsmetoder som inte undergräver oberoendet mellan enheter och den övergripande åtskillnaden av problem i hela systemet.

Interoperabilitet påverkar även kvaliteten på dina användarupplevelser. Dina användare förväntar sig att data som skapats i ett område (som orderinformation) kan användas i ett annat (som marknadsföringskampanjer), och dina byggare förväntar sig att om de lär sig göra något (som att bygga ett flöde eller autentisera till en API) kommer de att upptäcka att bekanta tekniker fungerar när de går vidare till nästa problem. Att misslyckas med att utforma för interoperabilitet kommer att resultera i överflödiga arkitekturer, replikerade data, processineffektivitet och ökade utvecklings- och supportkostnader.

Du kan skapa interoperabilitet i modulära system med meddelanden och händelser samt med API-hantering.

Meddelanden och händelser är två sätt att aktivera komponenter i ett system för att skicka och ta emot information. När det gäller det innehåll de kan bära liknar händelser och meddelanden varandra. En viktig skillnad är avsändarens beteende. En komponent som skickar ett meddelande skickar vanligtvis data till en specifik destination och väntar på något slags svar från mottagaren. Till skillnad från detta avger en komponent en händelse när något har hänt. Det finns ingen specifik destination eller en förväntan på ett svar. Dessa skillnader i beteende stöder olika kommunikationsmönster. Meddelanden har stöd för tillståndsbaserade kommunikationsmönster och händelser har stöd för tillståndslösa kommunikationsmönster. (Se Statsförvaltning för mer information om denna skillnad.)

Det är viktigt att justera team efter protokoll och användningsfall för meddelanden och händelser. Otydliga standarder kan resultera i en blandning av mönster i hela ditt system, vilket leder till:

• Problem med prestanda och skalbarhet där fel mönster tillämpas för ett specifikt användningsfall
• Inkonsekvent bearbetning som gör att systemet verkar instabilt för slutanvändare
• Längre felsökningstider och mer komplexa underhållsprocesser

Tänk på följande när du utformar meddelanden och händelser för att skapa mer löst kopplade strukturer inom din Salesforce-organisation:

• Identifiera synkroniserade och asynkrona användningsfall. Händelser tillåter löst kopplad, tillståndslös och asynkron kommunikation över ett system. Meddelanden möjliggör mer tätt kontrollerade, tillståndsbaserade och synkrona kommunikationsmönster. När du bestämmer när du ska använda meddelanden eller händelser måste du bestämma om din kommunikation måste vara synkron (och potentiellt blockerande) jämfört med asynkron och icke-blockerande.
• Definiera datastrukturer noggrant. Strukturen på den information som komponenterna skickar mellan sig är en viktig del av att hålla ett löst kopplat system hanterbart och sammanhängande. (Se API-hantering för mer information om detta.) En viktig faktor när du utformar ett meddelande eller en händelse är hur ofta informationens struktur kan behöva ändras. När ett meddelande eller händelsestruktur har definierats och implementerats i ditt system kan det vara svårt att hantera uppdateringar — särskilt om händelsen eller meddelandet redan används för att skicka information till ett externt system.
• Meddelanden i rätt storlek. I allmänhet rekommenderas att meddelandestorlekarna är små. Det finns dock även en balansgång mellan meddelandets storlek och volym. System kan bearbeta mindre mängder data snabbare. Bearbetningsåtgärden kommer med en mängd ytterligare overhead eftersom mottagare måste packa upp, tolka och avgöra vad de ska göra med information som de har fått. Dessa steg kan ta försumbar tid att utföra, men de kan bygga upp och skapa en börda på system i stor skala. Undvik konstruktioner som kräver att komponenter i systemet bearbetar många små meddelanden i följd för att utföra ett arbete. För att ändra rätt storlek på dina meddelanden, tänk på att utforma för det minsta antal data som komponenter längre ner måste bearbeta och agera på information som de har skickat, utan att även anta att varje komponent längre ner kommer att kunna begära eller bearbeta många uppföljningsmeddelanden.
• Design för skalbarhet. Löst kopplade komponenter kan göra det enklare att skala upp din arkitektur. Att eliminera korskomponentberoenden låter team arbeta med att förbättra prestanda eller skalbarhet för enskilda komponenter med minimal påverkan på de andra. Löst kopplade komponenter introducerar dock även betydande komplexitet i din arkitektur i stor skala (särskilt när det gäller att hantera status). Identifiera processer som behöver ha mer tätt kopplad logik eller beroenden av giltiga skäl för användarupplevelse eller dataintegritet — och försök inte introducera asynkrona/händelsebaserade mönster i dessa processer. Använd istället mönster baserade på synkronisering/meddelanden och korrekt felhantering.

Listan över mönster och antimönster nedan visar hur korrekta (och dåliga) meddelanden och händelser ser ut i en Salesforce-lösning. Du kan använda dessa för att validera dina konstruktioner innan du bygger, eller identifiera platser i ditt system som behöver omfaktoriseras.

Mer information om Salesforces meddelande- och händelseverktyg finns i Verktyg relevanta för komponerbara. Mer information om att välja ett händelsemönster eller verktyg för ett givet användningsfall finns i Arkitektens guide till händelsedriven arkitektur med Salesforce.

Att bygga korrekt hantering av programprogrammeringsgränssnitt (API) i en Salesforce-lösning låter enskilda komponenter i ditt system följa förutsägbara kommunikationsmönster. Salesforce tillhandahåller inbyggda, säkra API:n för kommunikation med system utanför Salesforce. (Mer information om Salesforce Platform API finns i Grundläggande arkitektur.)

Effektiv API-hantering inom Salesforce-lösningar är nyckeln till att bygga verkligt komponerbara arkitekturer. Den låter komponenter inuti en Salesforce-organisation skicka och ta emot information effektivt. Det låter även lösningsbyggare följa tydliga protokoll för hur komponenterna de bygger kommunicerar med andra komponenter i systemet och hjälper dem att tidigt identifiera dåliga implementeringar. Dessutom låter den lösningsbyggare fokusera mer på den specifika komponent de bygger eller refaktoriserar, vilket ökar produktiviteten och kvaliteten.

API-hantering på företagsnivå är ett separat ämne — och uppnås bäst med ett omfattande API-hanteringsverktyg. (Mer information om MuleSoft-perspektivet på detta ämne finns i Vad är API-hantering?).

Tänk på följande för att bygga API-hanteringsfunktioner i dina Salesforce-lösningar:

• Tänk på API som förutsägbara mönster eller kontrakt för kommunikation. Datatypen för indata- eller utdatavariabler, variabelnamn, den information som ska (eller inte ska) visas i ett givet mönster — dessa är nycklarna till effektiv API-hantering. Dessa definitioner ska visas i dina designstandarder och team ska kunna ta reda på hur dessa definitioner har implementerats i vissa delar av ditt system via din dokumentation. Ett sätt att se svårigheter med att koppla ändringar från ny utveckling till en integrationsmiljö är att se dem som bevis på var du har implementerat API-kommunikation dåligt (eller kanske ingen API-definition alls).

• Begränsa inte ditt tänkande kring API till enbart kod. Det som definierar en API i detta sammanhang är enhetligheten i meddelandestrukturerna och variablerna i det meddelandet. Så länge som denna enhetlighet upprätthålls kan en API implementeras i kod såväl som i deklarativa anpassningar, som modulära autostartade (eller plattformshändelseutlösta) flöden, eller till och med flödesmallar. Basera dina beslut på vad som ska definieras i kod jämfört med flöden, inte på API-implementering utan snarare på paketbarhet och testbarhet.

• Håll din livscykel och versionshantering enkel. Precis som alla delar av programutveckling har API en livscykel: definiera, bygg, testa, distribuera och underhåll (inklusive att dra sig tillbaka). Salesforce Platform API släpper flera versioner inom ett kalenderår, på grund av plattformens snabba releasecykel. (Du kan läsa mer om detta beteende i Salesforce Architecture Basics.) Detta innebär att plattforms-API har en ganska komplex livscykel, eftersom flera versioner av ett visst API måste underhållas och vara tillgängliga för Salesforce-kunder. Denna komplexitetsnivå är lämplig för PaaS-användningsfall — men det är troligen onödig komplexitet för dina arkitekturer för lösningar på plattform (se: Antimönster för läsbarhet). Fokusera på att definiera ett tydligt syfte med en API (till exempel felhantering) och tydliga baslinjedefinitioner. Sikta på att endast ha en version av varje API.

• Gör dina API upptäckbara, tillgängliga och hanterbara. Dokumentera dina API:n så att potentiella konsumenter enkelt kan hitta tillgängliga API:n som ansluter till dem. API måste fungera smidigt som en del av ett landskap av kapacitet.

• Var iterativ. Fokusera på att definiera och implementera endast en intern API åt gången. På så sätt kan du snabbt fokusera på att upprepa API-definitionen, hitta rätt formulär för din version som stöds och etablera bästa praxis från erfarenheterna av implementering.

Listan över mönster och antimönster nedan visar hur korrekt (och dålig) API-hantering ser ut i en Salesforce-lösning. Du kan använda dessa för att validera dina konstruktioner innan du bygger, eller identifiera områden i ditt system som behöver omfaktoriseras.

Mer information om verktyg som är tillgängliga från Salesforce för att hjälpa dig bygga mer interoperabilitet finns i Verktyg relevanta för komponerbara.

Följande tabell visar ett urval av mönster att leta efter (eller bygga) i din organisation och antimönster att undvika eller rikta in sig på för att åtgärda.

✨ Upptäck fler mönster för interoperabilitet i Mönster & Anti-Mattern Explorer.

Att skapa paketerbarhet i en Salesforce-organisation innebär att funktionalitet i organisationen kommer från enheter som kan utvecklas och distribueras oberoende och tillförlitligt, som paket. Det bästa är om dessa enheter definieras som en typ av andra generationens paket (antingen ett olåst paket eller ett hanterat paket för ISV:er). Obs! Eftersom välbyggda lösningar uteslutande använder dessa pakettyper omfattas inte första generationens hanterade paket här.

Det är en sak att definiera separationer av problem och skapa funktionella enheter i en Salesforce-organisation. Det är en annan sak att reda ut och hantera beroenden tillräckligt tydligt för att framgångsrikt versionera dessa enheter som paketartefakter. Att uppnå denna nivå av stabilitet och metadataisolering kräver en betydande nivå av DevOps (och arkitektonisk) mognad. Det snabbar även på utvecklingstiden, förbättrar appbyggarupplevelser och ger förutsägbarhet och kontroll till utgåvor och releasehantering. Inte alla organisationer kommer att kunna stödja den infrastruktur som krävs för att definiera, underhålla och utveckla effektiva paket. Men att uppnå paketerbarhet bör vara det slutgiltiga målet för nästan alla Salesforce-organisationer.

Du kan bygga paketerbarhet i dina Salesforce-lösningar genom att fokusera på lös koppling och beroendehantering.

I ett system med lös koppling är enskilda bitar inte starkt knutna till varandra. Många av fördelarna med ett kompositerbart system kommer från lös koppling. I paketerbara system, att uppnå lös koppling mellan paket (och installera organisationer) kommer att göra det möjligt för dig att ha väldefinierade paket och mer produktiva utvecklingscykler för team som arbetar med paket.

På Salesforce Platform kan du bygga paket som är tätt kopplade till en viss organisation. Denna kapacitet är användbar för att definiera funktionella enheter och experimentera med korrekt separering av problem i din organisation, allt eftersom din paketeringsmognad utvecklas. Om du väljer detta tillvägagångssätt kommer du dock att inse få av fördelarna med verkligt paketerbara metadata, inklusive källdriven utveckling, möjligheten att använda versioner och artefaktstabilitet. Istället kommer du sannolikt att fortsätta att uppleva nackdelarna med ett tätt kopplat system, inklusive:

• Enskilda felpunkter som orsakar avbrott och prestandaproblem
• Långsamma, oförutsägbara distribueringar
• Svåra, komplexa felsöknings- och felsökningscykler
• Problem med skala och prestanda

Slutmålet för alla paketerbara Salesforce-system är löst kopplade paket.

Tänk på följande när du tittar på att dela upp dina Salesforce-metadata i effektiva paket:

• Vilka anpassningar är data jämfört med metadata? När det gäller paketerbarhet behandlar Salesforce Platform data och metadata väldigt olika. Det är viktigt att förstå vilka funktioner i din organisation som är metadata eller data. Du kan inte inkludera data i några paketerade enheter. När du bestämmer var du ska börja abstrahera funktionalitet till en paketerad enhet måste dina team bestämma om anpassningar som lagras som data ska uteslutas från paketet helt eller omfaktoriseras till en metadatabaserad implementering.
• Hur paketering påverkar team. En logistisk verklighet för Salesforce-paketering är att mycket av arbetet med att skapa och släppa en paketversion kräver kompetens med Salesforce CLI och/eller CI/CD-tekniker. Detta innebär att både anpassningar med låg kod och programmatiska anpassningar kommer att kräva tid och uppmärksamhet från någon som kan arbeta med paketrelaterad DevOps-teknik. Beroende på hur ditt team hanterar funktionsleveranser kan paketanvändning orsaka betydande avmattning eller blockerare för olika team i en organisation. Du måste identifiera om team kommer att kunna hantera funktionsleverans via paketering och göra en plan för att åtgärda eventuella kompetens- eller personalluckor. Lösningar kan inkludera att börja använda parad programmering eller implementera CI/CD-jobb för utvecklingsmiljöer.
• Hur paketering kommer att förändra miljöstrategier. I en paketdriven utvecklingslivscykel bör tidigt arbete utföras i skissorganisationer. Dessa tillfälliga, källdrivna utvecklingsmiljöer möjliggör snabbare, mer iterativa cykler. De har även stöd för mer detaljerade miljöåtkomstkontroller för dina utvecklingsteam och större isolering från produktion. Ju fler beroenden dina paket har av opaketerade metadata eller data som endast finns i en sandbox eller produktionsmiljö, desto mindre troligt är det att team faktiskt kommer att kunna använda skissorganisationer. Du kan aktivera källspårning i sandboxar för att tillåta källdrivna utvecklingsmönster i miljöer som inte är skissorganisationer — men dina utvecklingsteam kommer inte att dra nytta av hastigheten och iterativ hastighet hos skissorganisationer.
• Hur paketversioner relaterar till utgåvor. Planera för hur ofta och i vilken fas av versionshantering för utvecklingspaket ska ske. Begäranden om paketversioner är begränsade (per organisation) på rullande basis under 24 timmar. Som en allmän rekommenderad metod, endast versionera ett paket när du är säker på att inget av paketets innehåll behöver ändras. Det bästa är om du provisionerar paketversioner efter att kvalitetssäkringsprocesserna har slutförts. Låt inte utvecklingsteam använda framgång eller misslyckande för begäranden om att skapa paket som "test" av hur väl de har definierat paketgränser. Det finns sätt att göra detta utan att försöka skapa versioner för en paketartefakt.
• Vad det idealiska slutläget ska stödja. Den idealiska paketeringsstrategin möjliggör kontrollerade, stabila Salesforce-utgåvor som kan utvecklas och levereras snabbt. Att definiera för många paket i hela din organisation kan skapa nya typer av komplexitet och flaskhalsar för utvecklingsteam. En alltför modulär organisation kan också orsaka att utgåvor blir långsamma och svåra. Börja med att bygga och släppa några versioner av ett enskilt, meningsfullt paket. Härled uppföljningspaket stegvis. Sluta introducera paket när du har en releasekadens som tjänar din verksamhet väl. Refaktorisera paket över tid om verksamhetsbehoven ändras eller releasekvaliteten försämras. Det idealiska paketets slutläge är subjektivt.

Oavsett hur du bestämmer dig för att definiera dina paket kommer du endast att kunna versionera ett löst kopplat paket genom effektiv beroendehantering.

Listan över mönster och antimönster nedan visar hur korrekt (och dålig) lös koppling ser ut för Salesforce-paketering. Du kan använda dessa för att validera dina konstruktioner innan du bygger, eller identifiera områden i ditt system som behöver omfaktoriseras.

Mer information om Salesforce-verktyg för att hjälpa dig bygga mer paketerbarhet finns i Verktyg relevanta för komponerbara.

I Salesforce-lösningar innebär beroendehantering att identifiera och strukturera relationerna mellan metadata i dina paket och metadata i de organisationer där dessa paket kommer att installeras. Beroendehantering är en viktig del av att utveckla stabila paketartefakter.

Beroenden kan strida mot strävan att skapa perfekt separerade, löst kopplade funktionella enheter. I ett idealiskt teknikläge har ett löst kopplat system inga beroenden mellan enheter. I verkligheten är det dock inte praktiskt att eliminera alla beroenden.

Balansen mellan att göra systemen läsbara och att använda företagsvänliga funktionella enheter kräver ofta kompromisser i form av perfekt isolering mellan enheterna i ett system. Mer pragmatiskt skapar kärntjänsterna som tillhandahålls av Salesforce Platforms standardfunktionalitet viktiga, nettopositiva beroenden för alla Salesforce-lösningar. Många inbyggda fördelar med skalbarhet, prestanda och säkerhet kommer från hur djupt integrerade de är i plattformen. När du utformar paketerbara Salesforce-lösningar är det viktigt att komma ihåg att paketberoenden inte är dåliga. Dålig beroendehantering är dåligt.

Effektiv beroendehantering med Salesforce-paketering innebär att utvecklings- och underhållsteam kan:

• Introducera nya projekt snabbare och med begränsad miljöåtkomst
• Utveckla och testa snabbt ändringar
• Förstå hur komplex funktionalitet ska levereras i mindre, specifika åtaganden
• Styr releasekadenser och minska systemunderhåll/releaseavbrottfönster
• Förutsägbart återkalla negativa ändringar i alla miljöer

Teknikerna för beroendehantering med Salesforce är ganska enkla:

• Använd meddelanden och händelser för att hantera graciösa överlämningar av statuslös eller tillståndslös information mellan komponenter.
• Använd egna metadatatyper för att tillhandahålla dynamisk körtidsinformation och för att stödja mönster för injektioner av beroenden.
• Låt Apex utvecklare använda abstrakta eller virtuella klasser.

I slutändan måste du bestämma vilka designmönster som tillåts i din organisation över deklarativ och programmatisk utveckling. De viktigaste övervägandena (arkitektoniskt) är att definiera var du vill lägga till mer teknisk komplexitet för att få färre beroenden, och var du behöver tolerera fler beroenden för att förenkla appbyggarens arbetsflöden.

När du bygger in strategier för beroendehantering i dina paket, tänk på de två primära organisationsprinciperna för paketenheter: horisontella och vertikala.

• Horisontala gränser. I horisontella paradigm abstraheras funktionalitet som kan behövas av mer än ett paket till ett horisontellt lager. Horisontella lager blir sedan källan till gemensam funktionalitet och nås via ett deklarerat beroende. Att minimera överflödig funktionalitet i alla paket föredras framför att minimera beroenden.
• Vertikala gränser. Vertikala paradigm maximerar isolering och lös koppling mellan delar av systemet. Delad funktionalitet är begränsad och liknande arbete kan visas mellan enheter. Beroenden är strikt begränsade för att maximera isolering mellan paketenheter.

Observera att detta inte är ett antingen/eller beslut. Du kan blanda vertikala och horisontella paradigm efter behov. Ofta är det snabbaste sättet att börja med ett paket att skapa horisontella servicelager. I takt med att skalan och komplexiteten i din paketanvändning växer kommer abstraktion av fler vertikala enheter att hjälpa till att förenkla komplexa miljökonfigurationsprocesser eller introduktioner för utvecklare.

Ett system med två funktionella enheter (A och B) kan till exempel struktureras med paketberoenden arrangerade i vertikala, horisontella och vertikala horisontella hybridparadigmer.

Oavsett vilket paketorganisationsparadigm du väljer finns det några absoluta saker att tänka på:

• Duplicera inte metadata mellan paket. Metadata som behövs för mer än ett paket ska abstraheras till ett eller flera paket som deklareras som beroenden.
• Använd de inbyggda beroendena för Salesforce Platform-metadata. För appbyggare ger de inbyggda tjänsterna som erbjuds av Salesforce Platform mycket funktionalitet som kan konfigureras snabbt. Många av dessa tjänster har inbyggda beroenden som gör dem svåra att abstrahera till funktionella enheter på låg nivå. För en given metadatatyp måste du förstå var den hamnar längs spektrumet av inbyggda beroenden och använda denna förståelse för att definiera dina paketberoendekedjor. Starta inte paketanvändning genom att försöka tvinga lös koppling till en bit standardplattformsfunktionalitet med många inbyggda beroenden. Det kommer att lägga till komplexitet (inte värde) när du når kapacitet i högre ordning. Det är också ett annat sätt att hamna i standardmönster jämfört med egna antimönster. Paketera metadata från botten (lägst beroenden) upp — och upprepa över tid.
• Håll koll på dina beroendekedjor. Undvik att skapa paketberoendekedjor som kräver att utvecklare delar upp sina ändringar i många olika paket åt gången.
• Fundera på vad som är vettigt för källkontroll. Det finns två grundläggande sätt att hantera dina paket i källkontroll. Det första är ett enskilt monorepo med paket isolerade i mappar. Det andra är flera arkiv med paket isolerade i sina egna arkiv. Det finns komplexiteter i att hantera varje typ av källstrategi, långsiktigt. När det gäller introduktioner av utvecklare är vertikala gränser mer effektiva i flera repoparadigmer. Horisontella gränser är mer lättförståeliga i en monorepo. Återigen kan du blanda och matcha strategier allt eftersom din arkitektur mognar.

Listan över mönster och antimönster nedan visar hur korrekt (och dålig) beroendehantering ser ut med Salesforce-paket. Du kan använda dessa för att validera dina konstruktioner innan du bygger, eller identifiera områden i ditt system som behöver omfaktoriseras.

Mer information om Salesforces verktyg för beroendehantering finns i Verktyg relevanta för komponerbara.

Följande tabell visar ett urval av mönster att leta efter (eller bygga) i din organisation och antimönster att undvika eller rikta in sig på för att åtgärda.

✨ Upptäck fler mönster för paketerbarhet i Mönster & Anti-Mattern Explorer.

Hjälp oss hålla Salesforce Well-Architected relevant för dig. Gå igenom vår undersökning för att ge feedback om detta innehåll och berätta vad du vill se härnäst.