Lees hier meer over onze updateschema's.

Composteerbare oplossingen passen zich snel en stabieler aan. Een systeem dat is ontworpen om samen te stellen, is opgebouwd uit betekenisvolle eenheden, of bouwstenen, die gracieus met elkaar kunnen werken en gemakkelijk in en uit gebruik kunnen worden verwisseld. Als u de samenstelling van een systeem inbouwt, kunt u nieuwe voorzieningen introduceren of technische problemen oplossen door afzonderlijke eenheden van een systeem opnieuw te factoriseren of opnieuw samen te stellen. Samenstelbaarheid maakt snellere, beter voorspelbare leveringscycli en releases mogelijk, omdat teams zich kunnen richten op het samenstellen en leveren van zinvolle voorzieningen via kleinere hoeveelheden wijzigingen.

Composteerbare systemen maken het mogelijk voor bedrijven om zich sneller en met meer stabiliteit aan te passen – of de stimulans nu intern is voor het bedrijf of wordt veroorzaakt door externe factoren. Composteerbare systemen zijn veerkrachtiger en kunnen oplossingen en architectonische patronen intensiever maken.

U kunt uw Salesforce-oplossingen beter samenstellen door drie belangrijke gewoontes te ontwikkelen: scheiding van zorgen, interoperabiliteit en pakketmogelijkheden. Hieronder kunt u de relatie van deze gewoonten op twee manieren zien: voor een enkele eenheid of in een samenstelbaar systeem, en over meerdere eenheden in een samenstelbaar systeem.

Een enkele, samenstelbare eenheid:

Een composeerbaar systeem:

Een fundamenteel concept in software engineering en systeemarchitectuur, scheiding van zorgen omvat het identificeren van verschillende zorgen binnen een groter systeem dat kan worden gescheiden in modulaire eenheden. Het bereiken van een sterke scheiding van zorgen binnen een systeem vereist het creëren van betekenisvolle eenheden voor toepassingslogica en functies binnen het hele systeem. Kleinere eenheden maken het voor leverings- en onderhoudsteams van apps gemakkelijker om te begrijpen hoe en waar ze wijzigingen moeten aanbrengen, met minimale onderbreking van het grotere systeem. Kleinere eenheden maken het ook duidelijker hoe en waar het werk moet worden gericht bij het aanpakken van technische schulden en dragen bij aan de algemene leesbaarheid van uw systeem.

U kunt zorgen beter scheiden in uw Salesforce-organisatie door u te richten op bedrijfscapaciteit en statusbeheer.

Voor Salesforce-systemen past de beste benadering voor het scheiden van zorgen een bedrijfsgericht perspectief toe voor het identificeren en organiseren van modulaire eenheden (of mogelijkheden) binnen het systeem. Dit is in tegenstelling tot een op engineering gerichte weergave, die eenheden identificeert op basis van hun technische functie. Een bedrijfsgericht perspectief in het scheiden van zorgen vereist het ordenen van de code en aanpassingen in uw systeem op basis van de service die ze leveren aan de zakelijke en zakelijke gebruikers. Deze benadering betekent niet dat het potentieel voor redundante of duplicerende technische functies in een systeem wordt genegeerd. Het betekent eerder dat technische diensten duidelijk worden toegewezen aan een organisatieprincipe dat uiteindelijk transparant is voor de onderneming.

Door u te richten op zakelijke mogelijkheden zorgt u ervoor dat de overdrachten tussen bedrijfsanalyse- en ontdekkingsteams aan leveringsteams zo eenvoudig mogelijk zijn. Als appsamenstellers geen idee hebben waar hun werkeenheden passen in uw samenstelbare architectuur, hebt u een puinhoop, geen samenstelbaar applandschap. Onduidelijke toewijzingen tussen de eindstatus die het bedrijf vereist en de modulaire eenheden binnen een organisatie vergroten ook de kans dat ontwikkelteams of leveranciers redundante functies in het systeem inbouwen.

Denk aan het volgende om functionele eenheden te richten op bedrijfsmogelijkheden:

• Begin met taken die moeten worden uitgevoerd. Focus op de taken die moeten worden uitgevoerd (JTBD) van gebruikers en het bedrijf zelf. De JTBD-benadering, gepionierd door Tony Ulwick, richt zich op het begrijpen van de "taak", of het ware doel, die mensen proberen te bereiken met behulp van een product of dienst. Het is een hoger abstractieniveau dan aan rollen gerelateerde taken van gebruikers of de afzonderlijke stappen in een bedrijfsproces. Taken zoals duplicaatcontroles en adresvalidaties kunnen bijvoorbeeld onder een hogere-ordefunctie vallen, namelijk "één weergave van de klant maken". Nadat u een duidelijk gevoel hebt van deze zakelijke mogelijkheden van hogere orde, kunt u beginnen met het toewijzen van onderdelen van uw systeem aan hen.
• Richt u op mogelijkheden, niet op rapportagestructuren. De interne hiërarchie van uw bedrijfseenheden is geen proxy voor zinvolle mogelijkheden of taken die moeten worden uitgevoerd. De interne hiërarchie van uw bedrijf heeft wel een materiële impact op processen en teamstructuren (en budgetten). Dat zijn belangrijke logistieke overwegingen. Maar de functionele behoeften van het bedrijf werken op een hoger abstractieniveau dan logistiek. Als u een module maakt om een rapportagestructuur te bedienen in plaats van een functie van hogere orde, moet u er rekening mee houden dat u mogelijk extra stappen moet ondernemen om te bepalen hoe die module zich verhoudt tot bedrijfsmogelijkheden.
• Wees herhalend. Begin door samen te werken met het bedrijf om te bepalen welke mogelijkheden kunnen werken voor een minimaal levensvatbaar product (MVP). Wanneer u een mogelijkheid identificeert, begint u met het samenstellen van die MVP. Identificeer tijdens het samenstellen de processen, metagegevens en events of berichten die centraal staan in de functionele eenheid die u maakt. Identificeer alle processen, metagegevens en events of berichten die externe afhankelijkheden zijn. Naarmate er meer functionele eenheden worden ontworpen, implementeert u API-beheer en afhankelijkheidsbeheer om eenheden samen te stellen die goed met elkaar werken (in plaats van silo-eenheden te bouwen).

De onderstaande lijst met patronen en antipatronen toont hoe de juiste (en slechte) oriëntatie op bedrijfsfuncties eruitziet binnen een Salesforce-oplossing. U kunt deze gebruiken om uw ontwerpen te valideren voordat u gaat bouwen, of om gebieden van uw systeem te identificeren die moeten worden aangepast.

Zie Tools Relevant to Composable voor meer informatie over tools die beschikbaar zijn vanuit Salesforce om u beter te laten kennismaken met zakelijke mogelijkheden.

Statusbeheer richt zich op de verplaatsing van informatie binnen een systeem op verschillende tijdstippen. Met effectief statusbeheer kunnen toepassingen complexe gegevensstromen of interacties afhandelen met een minimum aan ongeplande of onbepaalde uitkomsten. Status beheren in een modulaire Salesforce-organisatie betekent het samenstellen van duidelijke paden voor logicastromen binnen en tussen eenheden, evenals sierlijke paden voor ongeplande uitvoeringswerking. Statusbeheer maakt het mogelijk om coherente stromen logica te vormen vanuit modulaire Salesforce-toepassingseenheden. In de meeste gevallen vereist dit interoperabiliteit om de informatiestroom tussen eenheden te structureren.

Problemen bij het beheer van status binnen los gekoppelde eenheden leiden vaak tot monolithische toepassingsontwikkeling in Salesforce. U kunt dit zien in grote “monostromen”, die zijn samengesteld in een poging om een complex proces binnen één stroom te organiseren. Een ander voorbeeld is massieve Apex klassen, die complexe processen orkestreren door middel van spaghetticode, of een lange reeks methoden voor eenmalig gebruik. Deze typen toepassingsarchitecturen maken refactoren en foutopsporing moeilijk en verlengen de onboardingtijden voor nieuwe teamleden of leveranciers. Ze verminderen ook de waarde van de toepassingen die aan het bedrijf worden geleverd, omdat functionaliteit niet herbruikbaar is.

Denk aan het volgende als u de status wilt beheren in een modulaire Salesforce-organisatie:

• Beslis wanneer u statelijke versus stateloze patronen wilt gebruiken. Statische patronen bewaren informatie gedurende een uitvoeringstraject, staatloze patronen niet. In een los gekoppeld systeem maken staatloze patronen het mogelijk om componenten sneller en met minder bijwerkingen te refactoren. Statische patronen zijn echter niet geschikt voor alle gebruikscases. Als u componenten samenstelt voor gegevensbewerkingen, kunnen stateful patronen helpen bij de integriteit en consistentie van gegevens in uw systemen. Gebruik een statuspatroon als uw component voldoet aan een van de volgende criteria:
  • Bewustzijn van plaatsing binnen een groter uitvoeringstraject is essentieel voor de werking van de component
  • De werking van de component moet worden gewijzigd op basis van de resultaten van een actie verderop in de stroom (de uitvoering moet bijvoorbeeld worden gewijzigd op basis van terugdraai-/fout-/succesberichten van componenten verderop in de stroom)
  • De component moet wachten op reacties van een extern of downstream systeem om zijn werk te voltooien
• Maak betekenisvolle categorieën voor stateful informatie. State is een ambigue term die kan worden toegepast op een zo diep en breed scala aan informatie binnen (en buiten) een Salesforce-organisatie dat de term op zichzelf bijna betekenisloos is. Een noodzakelijke eerste stap voor het samenstellen van stateful patronen is daarom het maken van zinvolle categorieën voor de belangrijkste stateful uitvoeringstrajecten (of soorten stateful werkingen) binnen uw systeem. Enkele categorieën om te overwegen:
  • Navigatie en formulieren
  • Databasebewerkingen
  • Batch- en bulkbewerkingen
  • Fouten
• Definieer aan gegevens gerelateerde staten in termen van databasetransacties. De ingebouwde werking van het platform zal de meerderheid van de overwegingen bij de status voor gegevens in Salesforce beperken. Probeer dit gedrag niet te omzeilen. Ontwerp voor en met het. Ontwerp oplossingen die gedistribueerde transactielogica minimaliseren of elimineren. (Zie Gegevensverwerking voor meer details).
• Identificeer statussen die voorkomen binnen (en over) functionele eenheden. Wanneer u functionele eenheden samenvoegt in grotere systemen, moet u er rekening mee houden wanneer u statusloze en statusvolle componentwerking vermengt, en combinaties voorkomen die eindeloze lussen of hiaten in de verwerking kunnen veroorzaken.
• Definieer overdrachten. Denk na over welke componenten van berichtenverkeers- of eventingpatronen worden gebruikt om aan status gerelateerde gegevens naar een ander deel van het systeem te verzenden. Zorg ervoor dat u transactiebewustzijn en verwerking in uw componenten inbouwt. Neem geen gedistribueerde transactielogica op in uw overdrachten.
• Maak toewijzingen tussen uw procesdiagrammen en statussen. Procesdiagrammen geven details over de stappen die informatie op verschillende momenten door uw systeem verplaatsen. Een statusdiagram toont de feitelijke wijzigingen in de informatie (de status). Gebruik het gedeelte met de metagegevensvoettekst van de vormen van Salesforce-diagrammen om de veranderende status van informatie binnen elke stap van uw proces vast te leggen. Als u procesdiagrammen en statusdiagrammen scheidt, zorgt u ervoor dat u ze koppelt. Dit concept moet niet worden verward met het vastleggen van de huidige en toekomstige status van processen of systeemlandschappen tijdens het ontwerp en de implementatie, omdat het niet gaat om de informatie die door het systeem wordt verplaatst.

De onderstaande lijst met patronen en antipatronen toont hoe goed (en slecht) statusbeheer eruitziet binnen een Salesforce-oplossing. U kunt deze gebruiken om uw ontwerpen te valideren voordat u gaat bouwen, of om plekken in uw systeem te identificeren die moeten worden aangepast.

Zie Tools Relevant to Composable voor meer informatie over Salesforce-tools voor het beheren van status.

De volgende tabel toont een selectie van patronen die u in uw organisatie kunt zoeken (of samenstellen) en antipatronen die u kunt vermijden of die u kunt gebruiken voor herstel.

✨ Ontdek meer patronen voor het scheiden van zorgen in de Patroon & Anti-patroon Explorer.

In een systeem dat is ontworpen voor interoperabiliteit, kunnen componenten informatie uitwisselen en effectief samenwerken. Interoperabiliteit is essentieel om een modulair systeem samenstelbaar te maken in plaats van geïsoleerd. Interoperabiliteit kan moeilijk te bereiken zijn in een los gekoppeld systeem. U moet standaarden opstellen voor consistente methoden van integratie die de onafhankelijkheid tussen eenheden en de algemene scheiding van zorgen binnen het systeem niet ondermijnen.

Interoperabiliteit heeft ook invloed op de kwaliteit van uw gebruikerservaringen. Uw gebruikers verwachten dat gegevens die in het ene gebied worden gemaakt (zoals ordergegevens), bruikbaar zijn in een ander gebied (zoals marketingcampagnes), en uw samenstellers verwachten dat als ze leren hoe ze iets moeten doen (zoals een stroom samenstellen of authenticeren bij een API), ze merken dat bekende technieken werken wanneer ze doorgaan naar het volgende probleem. Het niet ontwerpen voor interoperabiliteit zal resulteren in redundante architecturen, gerepliceerde gegevens, procesinefficiënties en hogere ontwikkeling- en ondersteuningskosten.

U kunt interoperabiliteit in modulaire systemen maken met berichtenverkeer en eventing, evenals met API-beheer.

Berichten en events zijn twee manieren waarop u componenten binnen een systeem informatie kunt laten verzenden en ontvangen. Wat betreft de inhoud die ze kunnen dragen, lijken events en berichten op elkaar. Een belangrijk verschil is het gedrag van de afzender. Een component die een bericht verzendt, verzendt doorgaans gegevens naar een specifieke bestemming en wacht op een reactie van de ontvanger. Een component daarentegen zendt een event uit wanneer er iets is gebeurd. Er is geen specifieke bestemming, noch een verwachting van een reactie. Deze verschillen in gedrag ondersteunen verschillende communicatiepatronen. Berichten ondersteunen statusloze communicatiepatronen en events ondersteunen statusloze communicatiepatronen. (Zie Staatsbeheer voor meer informatie over dit onderscheid.)

Het is belangrijk om teams af te stemmen op protocollen en gebruikscases voor berichtenverkeer en eventing. Onduidelijke standaarden kunnen leiden tot een mix van patronen in uw systeem, wat leidt tot:

• Prestatie- en schaalbaarheidsproblemen waarbij de verkeerde patronen worden toegepast op een specifieke gebruikscase
• Inconsistente verwerking waardoor het systeem instabiel lijkt voor eindgebruikers
• Langere probleemoplossingstijden en complexere onderhoudsprocessen

Denk aan het volgende bij het ontwerpen van berichten en events om meer losjes gekoppelde structuren binnen uw Salesforce-organisatie te maken:

• Identificeer synchronisatie- en asynchrone gebruikscases. Eventing maakt los gekoppelde, staatloze en asynchrone communicatie binnen een systeem mogelijk. Berichtenverkeer zorgt voor strakker gecontroleerde, statige en synchrone communicatiepatronen. Wanneer u besluit wanneer u berichten of events wilt gebruiken, moet u bepalen of uw communicatie synchroon (en potentieel blokkerend) moet zijn ten opzichte van asynchroon en niet-blokkerend.
• Definieer gegevensstructuren zorgvuldig. De structuur van de informatie die componenten onderling doorgeven, is een belangrijk onderdeel van het beheersbaar en samenhangend houden van een los gekoppeld systeem. (Zie API-beheer voor meer informatie hierover.) Een belangrijke overweging bij het ontwerpen van een bericht of event is hoe vaak de structuur van de informatie moet worden gewijzigd. Zodra een bericht of eventstructuur is gedefinieerd en geïmplementeerd in uw systeem, kan het lastig zijn om updates af te handelen, vooral als de event of het bericht al wordt gebruikt om informatie naar een extern systeem te verzenden.
• Berichten met de juiste grootte. In het algemeen is het een best practice om de berichtgrootte klein te houden. Er is echter ook een afweging tussen de grootte van het bericht en het volume van het bericht. Systemen kunnen kleinere hoeveelheden gegevens sneller verwerken. De verwerking brengt extra overhead met zich mee, omdat ontvangers moeten uitpakken, interpreteren en bepalen wat ze moeten doen met de informatie die ze hebben ontvangen. Het voltooien van deze stappen kan een verwaarloosbare hoeveelheid tijd vergen, maar ze kunnen op schaal worden opgebouwd en een belasting vormen voor systemen. Vermijd ontwerpen waarbij componenten in het systeem veel kleine berichten achter elkaar moeten verwerken om een werkstuk te voltooien. Als u de juiste grootte van uw berichten wilt bepalen, kunt u overwegen om te ontwerpen voor de minimale gegevens die componenten verderop in de stroom nodig hebben om informatie die ze hebben verzonden, te verwerken en ernaar te handelen, zonder ook aan te nemen dat elke component verderop in de stroom in staat is om een groot aantal vervolgberichten te verzoeken of te verwerken.
• Ontwerp voor schaalbaarheid. Los gekoppelde componenten kunnen het schalen van uw architectuur vergemakkelijken. Het elimineren van afhankelijkheden tussen componenten stelt teams in staat om te werken aan het verbeteren van prestaties of schaalbaarheid van afzonderlijke componenten met minimale effecten op de andere componenten. Los gekoppelde componenten brengen echter ook een aanzienlijke complexiteit in uw architectuur op schaal (met name als het gaat om beheerstatus). Identificeer processen die nauwer gekoppelde logica of afhankelijkheden moeten hebben om geldige redenen voor gebruikerservaring of gegevensintegriteit — en probeer niet om op asynchrone/events gebaseerde patronen in die processen te introduceren. Gebruik in plaats daarvan op synchronisatie/berichten gebaseerde patronen en de juiste foutafhandeling.

De onderstaande lijst met patronen en antipatronen toont hoe goed (en slecht) berichtenverkeer en eventing eruitzien binnen een Salesforce-oplossing. U kunt deze gebruiken om uw ontwerpen te valideren voordat u gaat bouwen, of om plekken in uw systeem te identificeren die moeten worden aangepast.

Zie Tools Relevant voor Composable voor meer informatie over Salesforce-tools voor berichtenverkeer en eventing. Zie de Architectenhandleiding voor eventgestuurde architectuur met Salesforce voor meer informatie over het kiezen van een eventingpatroon of -tool voor een bepaalde gebruikscase.

Door het juiste beheer van de API (Application programming interface) binnen een Salesforce-oplossing samen te stellen, kunnen afzonderlijke componenten van uw systeem voorspelbare communicatiepatronen volgen. Salesforce biedt ingebouwde, veilige API's voor communicatie met systemen buiten Salesforce. (Zie Basisprincipes van architectuur voor meer informatie over Salesforce Platform-API's.)

Effectief API-beheer binnen Salesforce-oplossingen is essentieel voor het samenstellen van echt samenstelbare architecturen. Hiermee kunnen componenten binnen een Salesforce-organisatie efficiënt informatie verzenden en ontvangen. Het stelt oplossingssamenstellers ook in staat om duidelijke protocollen te volgen voor de manier waarop de componenten die ze samenstellen, communiceren met andere componenten in het systeem, en helpt ze om slechte implementaties vroeg te identificeren. Bovendien kunnen oplossingssamenstellers zich nauwkeuriger richten op het specifieke component dat ze samenstellen of refactoren, wat de productiviteit en kwaliteit ten goede komt.

API-beheer op ondernemingsniveau is een apart onderwerp en kan het best worden bereikt met een uitgebreide API-beheertool. (Zie Wat is API-beheer? voor meer informatie over het MuleSoft-perspectief over dit onderwerp.)

Denk aan het volgende om API-beheermogelijkheden samen te stellen binnen uw Salesforce-oplossingen:

• Zie API's als voorspelbare patronen of contracten voor communicatie. Het gegevenstype van invoer- of uitvoervariabelen, variabelennamen, de stukjes informatie die wel (of niet) in een bepaald patroon moeten worden weergegeven, dit zijn de sleutels tot effectief API-beheer. Deze definities moeten worden weergegeven in uw ontwerpnormen en teams moeten via uw documentatie kunnen achterhalen hoe deze definities zijn geïmplementeerd in bepaalde delen van uw systeem. Een manier om problemen met het samenvoegen van wijzigingen vanuit nieuwe ontwikkeling naar een integratieomgeving te bekijken, is door ernaar te kijken als bewijs van waar u API-communicatie slecht hebt geïmplementeerd (of misschien helemaal geen API-definitie).

• Beperk uw denken over API's niet tot uitsluitend code. Wat een API in deze context definieert, is de consistentie van de berichtstructuren en variabelen binnen dat bericht. Zolang die consistentie behouden blijft, kan een API zowel in code als in declaratieve aanpassingen worden geïmplementeerd, zoals modulaire automatisch gestarte (of door platformevents geactiveerde) stromen of zelfs stroomsjablonen. Baseer uw beslissingen op wat er in code moet worden gedefinieerd, niet op API-implementatie, maar op pakketmogelijkheden en testbaarheid.

• Houd uw levenscyclus en versiebeheer eenvoudig. Zoals alle onderdelen van toepassingsontwikkeling hebben API's een levenscyclus: definiëren, samenstellen, testen, implementeren en onderhouden (inclusief intrekken). Salesforce Platform-API's brengen binnen een kalenderjaar verschillende versies uit vanwege de snelle releasecyclus van het platform. (U kunt meer over deze werking lezen in Salesforce Architecture Basics.) Dit betekent dat platform-API's een vrij complexe levenscyclus hebben, aangezien verschillende versies van een bepaalde API moeten worden onderhouden en beschikbaar moeten zijn voor Salesforce-klanten. Dit niveau van complexiteit is geschikt voor PaaS-gebruikscases, maar het is hoogstwaarschijnlijk onnodige complexiteit voor uw on-platform oplossingsarchitecturen (zie: Herhaalbaarheid anti-patronen). Focus op het definiëren van een duidelijk doel voor een API (bijvoorbeeld foutafhandeling) en duidelijke baselinedefinities. Probeer slechts één versie van elke API te hebben.

• Maak uw API's vindbaar, toegankelijk en beheersbaar. Documenteer uw API's zodat potentiële consumenten gemakkelijk beschikbare API's kunnen vinden om ermee te verbinden. API's moeten soepel functioneren als onderdeel van een landschap van mogelijkheden.

• Wees herhalend. Focus op het definiëren en implementeren van slechts één interne API tegelijk. Zo kunt u zich snel concentreren op het herhalen van de API-definitie, de juiste vorm voor uw ene ondersteunde versie vinden en best practices vaststellen op basis van de ervaring met implementatie.

De onderstaande lijst met patronen en antipatronen toont hoe goed (en slecht) API-beheer eruitziet binnen een Salesforce-oplossing. U kunt deze gebruiken om uw ontwerpen te valideren voordat u gaat bouwen, of om gebieden van uw systeem te identificeren die moeten worden aangepast.

Zie Tools Relevant to Composable voor meer informatie over tools die beschikbaar zijn vanuit Salesforce om u te helpen meer interoperabiliteit te creëren.

De volgende tabel toont een selectie van patronen die u in uw organisatie kunt zoeken (of samenstellen) en antipatronen die u kunt vermijden of die u kunt gebruiken voor herstel.

✨ Ontdek meer patronen voor interoperabiliteit in de Patroon & Anti-patroon Explorer.

Het maken van pakketmogelijkheden in een Salesforce-organisatie betekent dat functionaliteit in de organisatie afkomstig is van eenheden die onafhankelijk en betrouwbaar kunnen worden ontwikkeld en geïmplementeerd, als pakketten. Idealiter worden deze eenheden gedefinieerd als een type pakket van de tweede generatie (een ontgrendeld pakket of een beheerd pakket voor ISV's). Opmerking: Omdat goed ontworpen oplossingen uitsluitend deze pakkettypen gebruiken, worden beheerde pakketten van de eerste generatie hier niet behandeld.

Scheidingen van belangen definiëren en functionele eenheden maken in een Salesforce-organisatie is één ding. Het is iets anders om afhankelijkheden duidelijk genoeg te ontwarren en te beheren om die eenheden met succes als pakketartefacten te versieren. Het bereiken van dat niveau van stabiliteit en metagegevensisolatie vereist een aanzienlijk niveau van DevOps (en architectonische) volwassenheid. Het versnelt ook de ontwikkeltijd, verbetert de ervaringen van de appsamensteller en biedt voorspelbaarheid en controle voor releases en releasebeheer. Niet elke organisatie is in staat om de infrastructuur te ondersteunen die nodig is voor het definiëren, onderhouden en ontwikkelen van effectieve pakketten. Maar het bereiken van pakketmogelijkheden zou het uiteindelijke doel moeten zijn voor bijna elke Salesforce-organisatie.

U kunt pakketmogelijkheden in uw Salesforce-oplossingen samenstellen door u te richten op losse koppelingen en afhankelijkheidsbeheer.

In een systeem met losse koppeling zijn afzonderlijke stukken niet sterk aan elkaar gebonden. Veel van de voordelen van een composeerbaar systeem komen voort uit losse koppelingen. In systemen die in een pakket kunnen worden opgenomen, zorgt het bereiken van een losse koppeling tussen pakketten (en het installeren van organisaties) ervoor dat u goed gedefinieerde pakketten en productievere ontwikkelingscycli hebt voor teams die met pakketten werken.

Op het Salesforce Platform kunt u pakketten samenstellen die nauw verbonden met een bepaalde organisatie zijn. Deze mogelijkheid is handig bij het definiëren van functionele eenheden en bij het experimenteren met de juiste scheiding van zorgen in uw organisatie, naarmate u volwassener wordt in het verpakken. Als u deze benadering kiest, zult u echter weinig van de voordelen van echt pakketbare metagegevens realiseren, inclusief brongestuurde ontwikkeling, de mogelijkheid om versiebeheer te gebruiken en artefactstabiliteit. In plaats daarvan zult u waarschijnlijk de nadelen van een strak gekoppeld systeem blijven ervaren, waaronder:

• Enkelvoudige foutpunten die uitval en prestatieproblemen veroorzaken
• Trage, onvoorspelbare implementaties
• Moeilijke, complexe foutopsporings- en probleemoplossingscycli
• Problemen met schaal en prestaties

Het einddoel voor elk pakketbaar Salesforce-systeem is los gekoppelde pakketten.

Denk aan het volgende wanneer u uw Salesforce-metagegevens wilt scheiden in effectieve pakketten:

• Wat aanpassingen zijn gegevens versus metagegevens. Als het gaat om pakketmogelijkheden, behandelt het Salesforce Platform gegevens en metagegevens heel verschillend. Het is belangrijk dat u begrijpt welke voorzieningen in uw organisatie metagegevens of gegevens zijn. U kunt geen gegevens opnemen in in een pakket opgenomen eenheden. Terwijl u besluit waar u begint met het abstraheren van functionaliteit in een in een pakket opgenomen eenheid, moeten uw teams bepalen of aanpassingen die zijn opgeslagen als gegevens, helemaal moeten worden uitgesloten van het pakket of moeten worden omgerekend naar een op metagegevens gebaseerde implementatie.
• Hoe verpakkingen teams beïnvloeden. Een logistieke realiteit van Salesforce-pakketten is dat veel van het werk van het produceren en vrijgeven van een pakketversie vaardigheid vereist met de Salesforce CLI en/of CI/CD-technologieën. Dit betekent dat zowel low-code als programmatische aanpassingen tijd en aandacht vereisen van iemand die in staat is om met pakketgerelateerde DevOps-technologie te werken. Afhankelijk van de manier waarop uw team de levering van voorzieningen beheert, kan pakketacceptatie aanzienlijke vertragingen of blokkades veroorzaken voor verschillende teams in een organisatie. U moet bepalen of teams de levering van voorzieningen via pakketten kunnen beheren en een plan maken om eventuele hiaten in vaardigheden of personeel op te lossen. Oplossingen kunnen bestaan uit het gebruik van gepaard programmeren of het implementeren van CI/CD-taken voor ontwikkelomgevingen.
• Hoe verpakkingen omgevingsstrategieën zullen veranderen. In een pakketgestuurde ontwikkelingslevenscyclus moet er vroeg werk worden verricht in nul-organisaties. Deze tijdelijke, brongestuurde ontwikkelomgevingen maken snellere, meer herhalende cycli mogelijk. Ze ondersteunen ook fijnmaziger toegangscontroles voor de omgeving voor uw ontwikkelteams en meer isolatie van de productie. Hoe meer afhankelijkheden uw pakketten hebben van niet-verpakte metagegevens of gegevens die alleen voorkomen in een sandbox- of productieomgeving, hoe kleiner de kans dat teams daadwerkelijk scratch-organisaties kunnen gebruiken. U kunt bron bijhouden inschakelen in sandboxen om brongestuurde ontwikkelingspatronen mogelijk te maken in niet-scratch-organisatieomgevingen, maar uw ontwikkelteams zullen niet profiteren van de snelheid en herhalende snelheid van scratch-organisaties.
• Hoe pakketversies zich verhouden tot releases. Plan hoe vaak en in welke fase van versiebeheer van ontwikkelingspakketten moet plaatsvinden. Verzoeken om pakketversies zijn beperkt (per organisatie) op een 24-uurs basis. Als algemene best practice geldt dat u alleen een versie van een pakket moet maken als u er zeker van bent dat er niets aan de inhoud van het pakket hoeft te worden gewijzigd. Idealiter levert u pakketversies nadat kwaliteitsborgingsprocessen zijn voltooid. Sta niet toe dat ontwikkelteams verzoeken om het maken van pakketten met succes of zonder succes gebruiken als "tests" van hoe goed ze pakketgrenzen hebben gedefinieerd. Er zijn manieren om dit te doen zonder te proberen een versie van een pakketartefact te maken.
• Wat de ideale eindtoestand moet ondersteunen. De ideale verpakkingsstrategie zorgt voor gecontroleerde, stabiele Salesforce-releases die snel kunnen worden ontwikkeld en geleverd. Het definiëren van te veel pakketten in uw organisatie kan nieuwe soorten complexiteiten en bottlenecks voor ontwikkelteams veroorzaken. Een te modulaire organisatie kan er ook voor zorgen dat releases traag en moeilijk verlopen. Begin met het samenstellen en vrijgeven van enkele versies van één betekenisvol pakket. Vervolgpakketten incrementeel afleiden. Stop met het introduceren van pakketten wanneer u een releasecadans hebt die uw bedrijf goed dient. Refactorpakketten in de loop van de tijd, als bedrijfsbehoeften veranderen of de releasekwaliteit afneemt. De ideale pakketeindstatus is subjectief.

Ongeacht de manier waarop u besluit om uw pakketten te definiëren, kunt u een losgekoppeld pakket alleen met succes versieren door middel van effectief afhankelijkheidsbeheer.

De onderstaande lijst met patronen en antipatronen toont hoe de juiste (en slechte) losse koppeling eruitziet voor Salesforce-pakketten. U kunt deze gebruiken om uw ontwerpen te valideren voordat u gaat bouwen, of om gebieden van uw systeem te identificeren die moeten worden aangepast.

Zie Tools Relevant voor Composable voor meer informatie over Salesforce-tools om u te helpen meer pakketmogelijkheden samen te stellen.

In de context van een Salesforce-oplossing betekent afhankelijkheidsbeheer het identificeren en structureren van de relaties tussen de metagegevens in uw pakketten en de metagegevens in de organisaties waarin die pakketten worden geïnstalleerd. Afhankelijkheidsbeheer is een belangrijk onderdeel van het ontwikkelen van stabiele pakketartefacten.

Afhankelijkheden kunnen haaks staan op inspanningen om perfect gescheiden, losjes gekoppelde functionele eenheden te maken. In een ideale technische toestand heeft een los gekoppeld systeem geen afhankelijkheden tussen eenheden. In de praktijk is het echter niet praktisch om alle afhankelijkheden te elimineren.

De balans tussen het leesbaar maken van systemen en het gebruik van bedrijfsvriendelijke functionele eenheden vereist vaak nadelen in termen van perfecte isolatie tussen de eenheden in een systeem. Pragmatischer is dat de kernservices van de standaardfunctionaliteit van het Salesforce Platform belangrijke, netpositieve afhankelijkheden creëren voor elke Salesforce-oplossing. Veel voordelen van ingebouwde schaalbaarheid, prestaties en beveiliging komen voort uit de mate waarin ze zijn geïntegreerd in het platform. Wanneer u pakketafhankelijke Salesforce-oplossingen ontwerpt, is het belangrijk om te onthouden dat pakketafhankelijkheden niet inherent slecht zijn. Slecht afhankelijkheidsbeheer is slecht.

Effectief afhankelijkheidsbeheer met Salesforce-pakketten betekent dat ontwikkelings- en onderhoudsteams:

• Sneller en met beperkte toegang tot de omgeving nieuwe projecten
• Snel wijzigingen ontwikkelen en testen
• Inzicht in de manier waarop complexe functionaliteit moet worden geleverd in kleinere, specifieke verplichtingen
• Regel releasecadansen en verminder systeemonderhoud/release-uitvalperioden
• Voorspelbaar terugdraaien van negatieve wijzigingen in elke omgeving

De technieken voor afhankelijkheidsbeheer met Salesforce zijn vrij eenvoudig:

• Gebruik berichtenverkeer en eventing voor het afhandelen van gracieuze overdrachten van staat- of staatloze informatie tussen componenten.
• Gebruik typen aangepaste metagegevens om dynamische run-time informatie te bieden en patronen voor injectie van afhankelijkheid te ondersteunen.
• Laat Apex ontwikkelaars abstracte of virtuele klassen gebruiken.

Uiteindelijk moet u bepalen welke ontwerppatronen zijn toegestaan in uw organisatie voor declaratieve en programmatische ontwikkeling. De belangrijkste overwegingen (architecturaal) zijn om te definiëren waar u meer technische complexiteit wilt toevoegen om minder afhankelijkheden te hebben, en waar u meer afhankelijkheden moet tolereren om werkstromen van de Appsamensteller te vereenvoudigen.

Terwijl u strategieën voor afhankelijkheidsbeheer inbouwt in uw pakketten, moet u rekening houden met de twee primaire organisatieprincipes voor pakketeenheden: horizontaal en verticaal.

• Horizontale grenzen. In horizontale paradigma's wordt functionaliteit die mogelijk door meer dan één pakket nodig is, geabstraheerd tot een horizontale laag. Horizontale lagen worden dan de bron van gemeenschappelijke functionaliteit en worden geopend via een gedeclareerde afhankelijkheid. Het minimaliseren van redundante functionaliteit binnen pakketten krijgt de voorkeur boven het minimaliseren van afhankelijkheden.
• Verticale grenzen. Verticale paradigma's maximaliseren isolatie en losse koppeling tussen onderdelen van het systeem. Gedeelde functionaliteit is beperkt en vergelijkbaar werk kan binnen eenheden worden weergegeven. Afhankelijkheden zijn strikt beperkt om de isolatie tussen pakketeenheden te maximaliseren.

Let op: dit is geen of/of beslissing. U kunt verticale en horizontale paradigma's naar behoefte door elkaar gebruiken. De snelste manier om met een pakket te beginnen is vaak het maken van horizontale servicelagen. Naarmate de schaal en complexiteit van de acceptatie van uw pakket groeit, zal het abstraheren van meer verticale eenheden helpen complexe set-upprocessen voor de omgeving of onboarding voor ontwikkelaars te vereenvoudigen.

Een systeem met twee functionele eenheden (A en B) kan bijvoorbeeld worden gestructureerd met pakketafhankelijkheden die zijn gerangschikt in verticale, horizontale en verticaal-horizontale hybride paradigma's.

Ongeacht het pakketorganisatieparadigma dat u kiest, zijn er enkele absolute waarden om in gedachten te houden:

• Dupliceer geen metagegevens voor meerdere pakketten. Metagegevens die meer dan één pakket nodig heeft, moeten worden geabstraheerd tot een of meer pakketten die als afhankelijkheden worden gedeclareerd.
• Maak gebruik van de ingebouwde afhankelijkheden van Salesforce Platform-metagegevens. Voor appsamenstellers bieden de ingebouwde services van het Salesforce Platform veel functionaliteit die snel kan worden geconfigureerd. Veel van deze services hebben ingebouwde afhankelijkheden die het moeilijk maken om ze te abstraheren tot functionele eenheden op laag niveau. Voor een bepaald metagegevenstype moet u begrijpen waar het valt binnen het spectrum van ingebouwde afhankelijkheden en dit inzicht gebruiken om uw pakketafhankelijkheidsketens te definiëren. Start pakketacceptatie niet door losse koppelingen af te dwingen in een stuk standaardplatformfunctionaliteit met veel ingebouwde afhankelijkheden. Het voegt complexiteit (niet waarde) toe naarmate u mogelijkheden van hogere orde bereikt. Het is ook een andere manier om in standaard versus aangepaste anti-patronen te vallen. Pak metagegevens van onderen (laagste afhankelijkheden) omhoog in een pakket op en herhaal dit in de loop van de tijd.
• Let op uw afhankelijkheidsketens. Vermijd het maken van pakketafhankelijkheidsketens die ontwikkelaars verplichten hun wijzigingen op te splitsen in vele verschillende pakketten tegelijk.
• Denk na over wat zinvol is voor bronregeling. Er zijn twee basismanieren om uw pakketten te beheren in bronregeling. De eerste is één monorepository met pakketten geïsoleerd binnen mappen. De tweede is meerdere repository's met pakketten die zijn geïsoleerd in hun eigen repository's. Er zijn complexiteiten aan het beheer van elk soort bronstrategie, op lange termijn. In termen van onboarding voor ontwikkelaars zijn verticale grenzen efficiënter in meerdere opslagparadigma's. Horizontale grenzen zijn begrijpelijker in een monorepository. U kunt strategieën opnieuw combineren naarmate uw architectuur volwassener wordt.

De onderstaande lijst met patronen en antipatronen toont hoe goed (en slecht) afhankelijkheidsbeheer eruitziet met Salesforce-pakketten. U kunt deze gebruiken om uw ontwerpen te valideren voordat u gaat bouwen, of om gebieden van uw systeem te identificeren die moeten worden aangepast.

Zie voor meer informatie over Salesforce-tools voor afhankelijkheidsbeheer Tools Relevant to Composable.

De volgende tabel toont een selectie van patronen die u in uw organisatie kunt zoeken (of samenstellen) en antipatronen die u kunt vermijden of die u kunt gebruiken voor herstel.

✨ Ontdek meer patronen voor pakketmogelijkheden in de Patroon & Anti-patroon Explorer.

Help ons Salesforce Well-Architected relevant voor u te houden; neem deel aan onze enquête om feedback te geven over deze inhoud en vertel ons wat u als volgende wilt zien.