Leggi qui le nostre pianificazioni degli aggiornamenti.

Le soluzioni componibili si adattano rapidamente e con maggiore stabilità. Un sistema progettato per essere componibile è costruito in unità significative, o blocchi di costruzione, che possono funzionare con grazia l'uno con l'altro e possono essere facilmente scambiati dentro e fuori servizio. La creazione della componibilità in un sistema consente di introdurre nuove funzionalità o di eliminare l'indebitamento tecnico rifattorizzando o rimontando singole unità di un sistema. La componibilità consente cicli di consegna e rilasci più rapidi e prevedibili, poiché i team possono concentrarsi sulla creazione e la fornitura di funzioni significative tramite piccole quantità di modifiche.

I sistemi componibili consentono alle imprese di adeguarsi più rapidamente e con maggiore stabilità, sia che lo stimolo sia interno all'azienda o causato da fattori esterni. La componibilità consente ai sistemi di essere più resilienti e può contribuire a rendere le soluzioni e gli schemi architettonici più intenzionali.

È possibile rendere le soluzioni Salesforce più componibili creando tre abitudini chiave: separazione delle preoccupazioni, interoperabilità e possibilità di inserire pacchetti. Di seguito è possibile vedere la relazione di queste abitudini in due modi: per una singola unità o in un sistema componibile e per più unità in un sistema componibile.

Una singola unità componibile:

Un sistema componibile:

Un concetto fondamentale nell'ingegneria del software e nell'architettura di sistema, la separazione delle preoccupazioni comporta l'identificazione di varie preoccupazioni all'interno di un sistema più grande che può essere separato in unità modulari. Il raggiungimento di una forte separazione delle preoccupazioni all'interno di un sistema richiede la creazione di unità significative per la logica di applicazione e le funzioni in tutto il sistema. Le unità più piccole semplificano la consegna e la manutenzione delle app per i team che devono capire come e dove apportare modifiche, con interruzioni minime al sistema più grande. Le unità più piccole consentono anche di capire meglio come e dove concentrare il lavoro quando si affronta il debito tecnico e contribuiscono alla leggibilità complessiva del sistema.

È possibile creare una migliore separazione delle preoccupazioni nell'organizzazione Salesforce orientandosi verso la capacità aziendale e lo stato di gestione.

Per i sistemi Salesforce, l'approccio migliore per la separazione delle preoccupazioni applica una prospettiva orientata al business per identificare e organizzare le unità modulari (o le funzionalità) all'interno del sistema. Questo è diverso da una visualizzazione focalizzata sull'ingegneria, che identifica le unità in base alla loro funzione tecnica. Una prospettiva orientata all'azienda indipendentemente dalle preoccupazioni richiede l'organizzazione del codice e delle personalizzazioni nel sistema in base al servizio che forniscono agli utenti aziendali e aziendali. Adottare questo approccio non significa ignorare il potenziale di funzioni tecniche ridondanti o duplicate in un sistema. Piuttosto, significa che i servizi tecnici sono chiaramente mappati a un principio organizzativo che in ultima analisi è trasparente per l'azienda.

L'orientamento alle funzionalità aziendali consente di garantire che i passaggi tra i team di analisi aziendale e di scoperta ai team di consegna siano il più semplici possibile. Se i generatori di app non hanno idea di dove le loro unità di lavoro vengono mappate nell'architettura componibile, significa che il panorama delle app non è componibile. Le mappature poco chiare tra lo stato finale richiesto dall'azienda e le unità modulari all'interno di un'organizzazione aumentano anche le possibilità che i team di sviluppo o i fornitori creino funzioni ridondanti nel sistema.

Considerare quanto segue per orientare le unità funzionali alla funzionalità aziendale:

• Iniziare con i lavori da eseguire. Concentrarsi sui processi da eseguire (JTBD) degli utenti e dell'azienda stessa. Pioniere di Tony Ulwick, l'approccio JTBD si concentra sulla comprensione del "lavoro", o vero scopo, che le persone stanno cercando di realizzare utilizzando un prodotto o servizio. È un livello di astrazione superiore rispetto alle operazioni correlate ai ruoli degli utenti o alle singole fasi di un processo aziendale. Ad esempio, operazioni come i controlli duplicati e le convalide degli indirizzi potrebbero rientrare in una funzione di ordine superiore di "stabilire una visualizzazione unica del cliente". Quando si ha un'idea chiara di queste funzionalità aziendali di livello superiore, è possibile iniziare a mapparvi parti del sistema.
• Orientarsi alle funzionalità, non alle strutture di creazione di rapporti. La gerarchia interna delle unità operative non è un proxy per le funzionalità o i processi significativi da eseguire. La gerarchia interna dell'azienda ha un impatto significativo sui processi e sulle strutture del team (per non parlare dei budget). Si tratta di considerazioni logistiche importanti. Ma le esigenze funzionali dell'azienda operano a un livello di astrazione superiore rispetto alla logistica. Se si sta creando un modulo per servire una struttura di rapporti anziché una funzione di ordine superiore, tenere presente che potrebbe essere necessario eseguire ulteriori operazioni per identificare in che modo il modulo è correlato alle funzionalità aziendali.
• Sii iterativo. Iniziare collaborando con l'azienda per identificare le funzionalità che potrebbero funzionare per un prodotto minimo vitale (MVP). Quando si identifica una funzionalità, iniziare a crearla come MVP. Durante la creazione, identificare i processi, i metadati e gli eventi o messaggi centrali per l'unità funzionale che si sta creando. Identificare eventuali processi, metadati ed eventi o messaggi che sono dipendenze esterne. Man mano che si progettano unità più funzionali, implementare la gestione API e la gestione delle dipendenze per creare unità che funzionano bene l'una con l'altra (anziché creare unità in silo).

L'elenco degli schemi e antischemi riportato di seguito mostra l'orientamento corretto (e inadeguato) alla funzione aziendale all'interno di una soluzione Salesforce. È possibile utilizzarli per convalidare i progetti prima di crearli o identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti disponibili in Salesforce che consentono di orientarsi meglio alle funzionalità aziendali, vedere Strumenti rilevanti per la composizione.

La gestione statale si concentra sulla circolazione delle informazioni in un sistema in vari punti nel tempo. Una gestione efficace dello stato consente alle applicazioni di gestire flussi complessi di dati o interazioni con un minimo di esiti non pianificati o indeterminati. Gestire lo stato in un'organizzazione Salesforce modulare significa creare percorsi chiari per i flussi di logica all'interno e tra le unità, nonché percorsi graziosi per i comportamenti di esecuzione non pianificati. La gestione dello stato consente di creare flussi coerenti di logica dalle unità di applicazione Salesforce modulari. Nella maggior parte dei casi, ciò richiede l'interoperabilità per strutturare il flusso di informazioni tra le unità.

Difficoltà di gestione dello stato tra unità vagamente accoppiate spesso portano allo sviluppo di applicazioni monolitiche in Salesforce. È possibile vedere questo in grandi "monoflussi", che sono costruiti nel tentativo di orchestrare un processo complesso all'interno di un flusso singolare. Un altro esempio sono le classi Apex massicce, che orchestrano processi complessi tramite spaghetti code, o una lunga serie di metodi monouso. Questi tipi di architetture applicative rendono difficile il refactoring e il debug e aumentano i tempi di orientamento per i nuovi membri del team o fornitori. Riducono anche il valore delle applicazioni fornite all'azienda, poiché le funzionalità non sono riutilizzabili.

Considerare quanto segue per gestire lo stato in un'organizzazione Salesforce modulare:

• Decidere quando utilizzare gli schemi stateful rispetto a quelli stateless. Gli schemi stateful conservano le informazioni in tutto un percorso di esecuzione, mentre gli schemi stateless non le conservano. In un sistema vagamente accoppiato, gli schemi stateless consentono di rifattorizzare i componenti più rapidamente e con meno effetti collaterali. Tuttavia, gli schemi stateless non sono appropriati per tutti i casi d'uso. Se si creano componenti per le operazioni sui dati, gli schemi statici possono essere utili per l'integrità e la coerenza dei dati in tutti i sistemi. Utilizzare uno schema stateful se il componente soddisfa uno dei seguenti criteri:
  • La consapevolezza della posizione all'interno di un percorso di esecuzione più ampio è essenziale per il comportamento del componente
  • Il comportamento del componente deve cambiare in base ai risultati di un'azione a valle (ad esempio, deve modificare l'esecuzione in base ai messaggi di ritiro/errore/successo dei componenti a valle)
  • Il componente deve attendere le risposte da un sistema esterno o a valle per completare il lavoro
• Creare categorie significative per informazioni dettagliate. Stato è un termine ambiguo che può essere applicato a una gamma così ampia e profonda di informazioni all'interno (e all'esterno) di un'organizzazione Salesforce che il termine da solo è quasi privo di significato. Un primo passo necessario per creare schemi stateful è quindi la creazione di categorie significative per i più importanti percorsi di esecuzione stateful (o tipi di comportamenti stateful) all'interno del sistema. Alcune categorie da considerare:
  • Navigazione e moduli
  • Operazioni sul database
  • Operazioni batch e in blocco
  • Errori
• Definire gli stati correlati ai dati in termini di transazioni del database. I comportamenti incorporati della piattaforma circoscriveranno la maggior parte delle considerazioni relative allo stato dei dati in Salesforce. Non tentare di gestire questo comportamento o di aggirarlo. Progettare per e con esso. Progettare soluzioni che riducono al minimo o eliminano la logica delle transazioni distribuite. (Per ulteriori dettagli, vedere Gestione dei dati).
• Identificare gli stati che si verificano all'interno (e tra) le unità funzionali. Quando si assemblano le unità funzionali in sistemi più grandi, tenere presente quando si mescolano il comportamento dei componenti stateless e stateful e impedire combinazioni che potrebbero creare loop o interruzioni infinite nell'elaborazione.
• Definire i passaggi. Considerare quali schemi di messaggistica o eventi verranno utilizzati dai componenti per trasmettere i dati relativi allo stato a un'altra parte del sistema. Assicurarsi di acquisire consapevolezza e gestione delle transazioni nei componenti. Non includere alcuna logica di transazione distribuita nelle consegne.
• Creare mappature tra i diagrammi e gli stati del processo. I diagrammi dei processi descrivono in dettaglio le fasi che spostano le informazioni nel sistema in vari punti nel tempo. Un diagramma dello stato mostra le modifiche effettive nelle informazioni (lo stato). Utilizzare la parte piè di pagina dei metadati delle forme dei diagrammi Salesforce per acquisire lo stato mutevole delle informazioni in ogni fase del processo. Se si separano diagrammi di processo e diagrammi di stato, assicurarsi di collegarli. Questo concetto non deve essere confuso con l'acquisizione dello stato attuale e futuro dei processi o dei paesaggi del sistema durante la progettazione e l'implementazione, poiché non si tratta delle informazioni che passano attraverso il sistema.

L'elenco degli schemi e antischemi riportato di seguito mostra l'aspetto di una corretta (e scarsa) gestione dello stato all'interno di una soluzione Salesforce. È possibile utilizzarli per convalidare i progetti prima di crearli o identificare i punti del sistema che devono essere sottoposti a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per la gestione dello stato, vedere Tools Relevant to Composable.

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri schemi per la separazione delle preoccupazioni in Pattern & Anti-Pattern Explorer.

In un sistema progettato per l'interoperabilità, i componenti possono scambiare informazioni e operare insieme in modo efficace. L'interoperabilità è fondamentale per rendere un sistema modulare componibile anziché in silo. L'interoperabilità può essere difficile da ottenere in un sistema accoppiato. È necessario stabilire standard per metodi di integrazione coerenti che non compromettano l'indipendenza tra le unità e la separazione delle preoccupazioni in tutto il sistema.

L'interoperabilità influisce anche sulla qualità delle esperienze utente. Gli utenti si aspettano che i dati creati in un'area (ad esempio le informazioni sugli ordini) siano utilizzabili in un'altra (ad esempio le campagne di marketing), mentre i generatori si aspettano che, se imparano a fare qualcosa (ad esempio creare un flusso o autenticarsi in un'API), troveranno le tecniche familiari quando passeranno al problema successivo. La mancata progettazione per l'interoperabilità determinerà architetture ridondanti, dati replicati, inefficienze dei processi e un aumento dei costi di sviluppo e assistenza.

È possibile creare interoperabilità nei sistemi modulari con messaggistica ed eventing e con la gestione API.

Messaggi ed eventi sono due modi in cui è possibile abilitare i componenti in un sistema per inviare e ricevere informazioni. In termini di contenuto che possono trasportare, gli eventi e i messaggi sono simili. Una differenza fondamentale è il comportamento del mittente. Un componente che invia un messaggio in genere invia i dati a una destinazione specifica e attende una risposta dal destinatario. Al contrario, un componente genera un evento quando è accaduto qualcosa. Non esiste una destinazione specifica, né un'aspettativa di risposta. Queste differenze di comportamento supportano modelli di comunicazione diversi. I messaggi supportano schemi di comunicazione stateful e gli eventi supportano schemi di comunicazione stateless. (Per ulteriori informazioni su questa distinzione, vedere Gestione statale).

È importante allineare i team sui protocolli e sui casi d'uso per la messaggistica e gli eventi. Standard poco chiari possono causare un mix di schemi in tutto il sistema, che porta a:

• Problemi di prestazioni e scalabilità in cui vengono applicati schemi errati a un caso d'uso specifico
• Elaborazione incoerente che rende il sistema instabile agli utenti finali
• Tempi di risoluzione dei problemi più lunghi e processi di manutenzione più complessi

Quando si progettano messaggi ed eventi per creare strutture più vagamente accoppiate all'interno dell'organizzazione Salesforce, tenere presente quanto segue:

• Identificare i casi d'uso di sincronizzazione e asincrono. L'evento consente comunicazioni vagamente accoppiate, apolidi e asincrone in un sistema. La messaggistica consente schemi di comunicazione più controllati, statici e sincroni. Quando si decide quando utilizzare i messaggi o gli eventi, è necessario decidere se la comunicazione deve essere sincrona (e potenzialmente bloccante) anziché asincrona e non bloccante.
• Definire attentamente le strutture dati. La struttura delle informazioni che i componenti passano tra loro è una parte importante per mantenere gestibile e coerente un sistema vagamente accoppiato. (Per ulteriori informazioni, vedere Gestione API). Una considerazione fondamentale quando si progetta un messaggio o un evento è la frequenza con cui può essere necessario modificare la struttura delle informazioni. Una volta definito e implementato un messaggio o una struttura di evento nel sistema, può essere difficile gestire gli aggiornamenti, soprattutto se l'evento o il messaggio viene già utilizzato per inviare informazioni a un sistema esterno.
• Messaggi delle dimensioni giuste. In generale, è consigliabile mantenere le dimensioni dei messaggi piccole. Tuttavia, esiste anche un bilanciamento tra dimensioni e volume dei messaggi. I sistemi possono elaborare più rapidamente piccole quantità di dati. L'atto di elaborazione comporta un sovraccarico aggiuntivo poiché i destinatari devono disimballare, interpretare e determinare cosa fare con le informazioni ricevute. Questi passaggi possono richiedere una quantità trascurabile di tempo, ma possono creare un carico sui sistemi su larga scala. Evitare le progettazioni che richiedono che i componenti del sistema elaborino molti piccoli messaggi in sequenza per completare un lavoro. Per dimensionare correttamente i messaggi, pensare alla progettazione per i componenti a valle di dati minimi che dovranno elaborare e agire correttamente sulle informazioni che sono state inviate, senza presumere che ogni componente a valle sarà in grado di richiedere o elaborare numerosi messaggi di follow-up.
• Progettazione per scalabilità. I componenti liberamente accoppiati possono semplificare la scalabilità dell'architettura. L'eliminazione delle dipendenze tra i componenti consente ai team di migliorare le prestazioni o la scalabilità di un singolo componente con effetti minimi sugli altri. Tuttavia, i componenti vagamente accoppiati introducono anche una complessità significativa nell'architettura su larga scala (soprattutto quando si tratta di gestire lo stato). Identificare i processi che necessitano di una logica o di dipendenze più strette per motivi di esperienza utente o integrità dei dati validi e non tentare di introdurre schemi asincroni/basati sugli eventi in tali processi. Utilizzare invece schemi basati su sincronizzazione/messaggi e una corretta gestione degli errori.

L'elenco di schemi e antischemi riportato di seguito mostra l'aspetto corretto (e scadente) della messaggistica e degli eventi all'interno di una soluzione Salesforce. È possibile utilizzarli per convalidare i progetti prima di crearli o identificare i punti del sistema che devono essere sottoposti a refactoring.

Per ulteriori informazioni sugli strumenti di messaggistica ed eventing di Salesforce, vedere Strumenti rilevanti per i componenti. Per ulteriori informazioni sulla scelta di uno schema di evento o di uno strumento per un determinato caso d'uso, vedere Architect’s Guide to Event-Driven Architecture with Salesforce.

La creazione di una gestione API (Application Programming Interface) corretta all'interno di una soluzione Salesforce consente ai singoli componenti del sistema di seguire schemi di comunicazione prevedibili. Salesforce fornisce API protette incorporate da utilizzare per la comunicazione con sistemi esterni a Salesforce. (Per ulteriori informazioni sulle API Salesforce Platform, vedere Nozioni di base sull'architettura).

Una gestione efficace delle API all'interno delle soluzioni Salesforce è fondamentale per creare architetture realmente componibili. Consente ai componenti di un'organizzazione Salesforce di inviare e ricevere informazioni in modo efficiente. Consente inoltre ai generatori di soluzioni di seguire protocolli chiari per il modo in cui i componenti che creano comunicano con altri componenti del sistema e li aiuta a identificare precocemente le implementazioni inadeguate. Inoltre, consente ai costruttori di soluzioni di concentrarsi più strettamente sul componente specifico che stanno creando o eseguendo il refactoring, aumentando la produttività e la qualità.

La gestione API a livello aziendale è un argomento a sé stante e può essere realizzata al meglio con uno strumento di gestione API completo. (Per ulteriori informazioni sulla prospettiva MuleSoft su questo argomento, vedere Che cos'è.)

Considerare quanto segue per creare funzionalità di gestione API all'interno delle soluzioni Salesforce:

• Pensare alle API come schemi o contratti prevedibili per la comunicazione. Il tipo di dati delle variabili di input o output, i nomi delle variabili, le informazioni che devono (o non devono) apparire in un determinato schema: queste sono le chiavi per una gestione efficace dell'API. Queste definizioni dovrebbero comparire negli standard di progettazione e i team dovrebbero essere in grado di scoprire come queste definizioni sono state implementate in particolari parti del sistema tramite la documentazione. Un modo per visualizzare le difficoltà di unione delle modifiche da un nuovo sviluppo in un ambiente di integrazione è quello di considerarle come una prova di dove le comunicazioni API sono state implementate in modo non corretto (o forse non è stata definita alcuna API).

• Non limitare il pensiero sulle API esclusivamente al codice. Ciò che definisce un'API in questo contesto è la coerenza delle strutture e delle variabili del messaggio all'interno del messaggio. A condizione che venga mantenuta tale coerenza, un'API può essere implementata nel codice e nelle personalizzazioni dichiarative, ad esempio nei flussi AutoLaunched modulari (o attivati da eventi piattaforma) o persino nei modelli di flusso. Basare le decisioni su ciò che definire nel codice e non nei flussi sull'implementazione dell'API, ma piuttosto sulla disponibilità dei pacchetti e sulla verificabilità.

• Semplificare il ciclo di vita e il controllo delle versioni. Come tutte le parti dello sviluppo delle applicazioni, le API hanno un ciclo di vita: definire, creare, testare, distribuire e mantenere (incluso il ritiro). Le API Salesforce Platform rilasciano diverse versioni in un anno di calendario, a causa del ciclo di rilascio rapido della piattaforma. (Ulteriori informazioni su questo comportamento sono disponibili in Salesforce Architecture Basics). Ciò significa che le API piattaforma hanno un ciclo di vita abbastanza complesso, poiché è necessario mantenere e rendere disponibili diverse versioni di una determinata API per i clienti Salesforce. Questo livello di complessità è appropriato per i casi d'uso PaaS, ma molto probabilmente è una complessità inutile per le architetture delle soluzioni on-platform (vedere: Anti-schemi di leggibilità). Concentrarsi sulla definizione di uno scopo chiaro per un'API (ad esempio, la gestione degli errori) e di definizioni di base chiare. Cercare di avere una sola versione di ogni API.

• Rendere le API individuabili, accessibili e gestibili. Documentare le API in modo che i potenziali consumatori possano trovare facilmente le API disponibili per connettersi a loro. Le API devono funzionare senza problemi come parte di un panorama di funzionalità.

• Sii iterativo. Concentrarsi sulla definizione e l'implementazione di una sola API interna alla volta. In questo modo, è possibile concentrarsi sull'iterazione rapida della definizione API, trovare il modulo giusto per la versione supportata e stabilire le procedure consigliate in base all'esperienza di implementazione.

L'elenco di schemi e antischemi riportato di seguito mostra l'aspetto corretto (e inadeguato) della gestione API all'interno di una soluzione Salesforce. È possibile utilizzarli per convalidare i progetti prima di crearli o identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti disponibili in Salesforce per migliorare l'interoperabilità, vedere Strumenti rilevanti per la composizione.

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri schemi per l'interoperabilità in Pattern & Anti-Pattern Explorer.

La creazione della possibilità di inserire pacchetti in un'organizzazione Salesforce significa che le funzionalità dell'organizzazione provengono da unità che possono essere sviluppate e distribuite in modo indipendente e affidabile, come pacchetti. Idealmente, queste unità sono definite come un tipo di pacchetto di seconda generazione (un pacchetto sbloccato o un pacchetto gestito per gli ISV). Nota: Poiché le soluzioni ben progettate utilizzano esclusivamente questi tipi di pacchetti, i pacchetti gestiti di prima generazione non sono trattati qui.

Una cosa è definire separazioni delle preoccupazioni e creare unità funzionali in un'organizzazione Salesforce. Un'altra cosa è districarsi e gestire le dipendenze in modo abbastanza chiaro da poterli utilizzare correttamente come artefatti del pacchetto. Il raggiungimento di tale livello di stabilità e isolamento dei metadati richiede un livello significativo di maturità di DevOps (e dell'architettura). Accelera inoltre i tempi di sviluppo, migliora le esperienze del generatore di app e offre prevedibilità e controllo ai rilasci e alla gestione dei rilasci. Non tutte le organizzazioni saranno in grado di supportare l'infrastruttura necessaria per definire, gestire e sviluppare pacchetti efficaci. Tuttavia, il raggiungimento della possibilità di inserire pacchetti dovrebbe essere l'obiettivo finale per quasi tutte le organizzazioni Salesforce.

È possibile creare pacchetti nelle soluzioni Salesforce concentrandosi sull'accoppiamento flessibile e sulla gestione delle dipendenze.

In un sistema con accoppiamento sciolto, i singoli pezzi non sono strettamente legati tra loro. Molti dei vantaggi di un sistema componibile derivano dall'accoppiamento flessibile. Nei sistemi inseribili in pacchetti, ottenere un accoppiamento flessibile tra i pacchetti (e installare le organizzazioni) consentirà di avere pacchetti ben definiti e cicli di sviluppo più produttivi per i team che utilizzano i pacchetti.

In Salesforce Platform è possibile creare pacchetti strettamente legati a una determinata organizzazione. Questa funzionalità è utile per definire le unità funzionali e sperimentare una corretta separazione delle preoccupazioni nell'organizzazione, man mano che si procede nella maturità dei pacchetti. Se si sceglie questo approccio, tuttavia, si noteranno alcuni dei vantaggi dei metadati realmente inseribili in pacchetti, tra cui lo sviluppo basato sulla fonte, la possibilità di utilizzare il controllo delle versioni e la stabilità degli artefatti. Al contrario, probabilmente continuerai a sperimentare gli svantaggi di un sistema strettamente accoppiato, tra cui:

• Singoli punti di errore che causano interruzioni e problemi di prestazioni
• Implementazioni lente e imprevedibili
• Cicli di debug e risoluzione dei problemi difficili e complessi
• Problemi di scala e prestazioni

L'obiettivo finale di qualsiasi sistema Salesforce inseribile in pacchetti è costituito da pacchetti vagamente accoppiati.

Considerare quanto segue quando si esamina la separazione dei metadati Salesforce in pacchetti efficaci:

• Quali personalizzazioni sono dati e quali metadati. Quando si tratta di inseribilità in pacchetti, Salesforce Platform tratta i dati e i metadati in modo molto diverso. È importante capire quali funzioni dell'organizzazione sono metadati o dati. Non è possibile includere dati in alcuna unità inserita in un pacchetto. Quando si decide da dove iniziare ad astrarre le funzionalità in un'unità inserita in un pacchetto, i team dovranno decidere se le personalizzazioni memorizzate come dati devono essere escluse completamente dal pacchetto o reinserite in un'implementazione basata sui metadati.
• In che modo la creazione di pacchetti avrà effetto sui team. Una realtà logistica del packaging Salesforce è che gran parte del lavoro di produzione e rilascio di una versione del pacchetto richiede competenza con le tecnologie Salesforce CLI e/o CI/CD. Ciò significa che le personalizzazioni a basso codice e a livello di programmazione richiederanno tempo e attenzione da parte di qualcuno in grado di lavorare con la tecnologia DevOps correlata ai pacchetti. A seconda di come il team gestisce la consegna delle funzioni, l'adozione dei pacchetti può causare rallentamenti o blocchi significativi ai diversi team di un'organizzazione. Sarà necessario identificare se i team saranno in grado di gestire la consegna delle funzioni tramite pacchetti ed elaborare un piano per risolvere eventuali lacune di competenze o di personale. Le soluzioni possono includere l'adozione di programmi abbinati o l'implementazione di processi CI/CD per gli ambienti di sviluppo.
• Come il packaging cambierà le strategie ambientali. In un ciclo di vita di sviluppo basato su pacchetto, il lavoro iniziale dovrebbe essere eseguito nelle organizzazioni vuote. Questi ambienti di sviluppo temporanei basati sulla fonte consentono cicli più rapidi e iterativi. Supportano inoltre controlli di accesso all'ambiente più granulari per i team di sviluppo e un maggiore isolamento dalla produzione. Maggiore è il numero di dipendenze dei pacchetti dai metadati o dai dati non inseriti in pacchetti che esistono solo in un ambiente Sandbox o di produzione, minore è la probabilità che i team siano in grado di utilizzare effettivamente le organizzazioni vuote. È possibile abilitare il tracciamento sorgente nei Sandbox per tenere conto degli schemi di sviluppo basati sulla fonte negli ambienti delle organizzazioni non vuote, ma i team di sviluppo non trarranno vantaggio dalla velocità e dalla velocità iterativa delle organizzazioni vuote.
• Come le versioni del pacchetto sono correlate ai rilasci. Pianificare la frequenza e la fase di sviluppo del controllo delle versioni dei pacchetti. Le richieste di versione del pacchetto sono limitate (per organizzazione) su base continuativa di 24 ore. Come procedura consigliata in generale, eseguire la versione di un pacchetto solo quando si è certi che non sia necessario modificare alcun contenuto del pacchetto. L'ideale è eseguire il provisioning delle versioni del pacchetto al termine dei processi di controllo della qualità. Non consentire ai team di sviluppo di utilizzare l'esito positivo o negativo delle richieste di creazione di pacchetti come "test" della qualità dei confini dei pacchetti. Esistono modi per eseguire questa operazione senza tentare di eseguire la versione di un artefatto del pacchetto.
• Quello che dovrebbe supportare l'end-state ideale. La strategia di creazione pacchetti ideale consente rilasci Salesforce controllati e stabili che possono essere sviluppati e consegnati rapidamente. Definire troppi pacchetti nell'organizzazione può generare nuovi tipi di complessità e colli di bottiglia per i team di sviluppo. Un'organizzazione eccessivamente modulare può anche causare rilasci lenti e difficili. Iniziare creando e rilasciando alcune versioni di un singolo pacchetto significativo. Derivare i pacchetti di follow-on in modo incrementale. Smettere di introdurre pacchetti quando si dispone di una cadenza di rilascio adatta alla propria azienda. Eseguire il refactoring dei pacchetti nel tempo, se le esigenze aziendali cambiano o se la qualità del rilascio diminuisce. Lo stato finale ideale del pacchetto è soggettivo.

Indipendentemente da come si decide di definire i pacchetti, la versione di un pacchetto vagamente accoppiato verrà eseguita correttamente solo tramite un'efficace gestione delle dipendenze.

L'elenco di schemi e antischemi riportato di seguito mostra l'aspetto corretto (e scadente) dell'accoppiamento sciolto per gli imballaggi Salesforce. È possibile utilizzarli per convalidare i progetti prima di crearli o identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce che consentono di creare pacchetti più completi, vedere Strumenti pertinenti per la composizione.

Nel contesto di una soluzione Salesforce, per gestione delle dipendenze si intende l'identificazione e la strutturazione delle relazioni tra i metadati dei pacchetti e i metadati delle organizzazioni in cui verranno installati. La gestione delle dipendenze è una parte fondamentale dello sviluppo di artefatti di pacchetti stabili.

Le dipendenze possono essere in contrasto con gli sforzi per creare unità funzionali perfettamente separate e accoppiate liberamente. In uno stato ingegneristico ideale, un sistema vagamente accoppiato non ha dipendenze tra le unità. Nel mondo reale, tuttavia, eliminare tutte le dipendenze non è pratico.

Spesso, l'equilibrio tra rendere i sistemi leggibili e utilizzare unità funzionali adatte alle aziende richiede un compromesso in termini di perfetto isolamento tra le unità di un sistema. Più pragmaticamente, i servizi di base forniti dalle funzionalità standard di Salesforce Platform creano dipendenze chiave positive per qualsiasi soluzione Salesforce. Molti vantaggi di scalabilità, prestazioni e sicurezza incorporati derivano dalla profondità con cui sono integrati nella piattaforma. Quando si progettano soluzioni Salesforce inseribili in pacchetti, è importante ricordare che le dipendenze dei pacchetti non sono intrinsecamente negative. Una cattiva gestione delle dipendenze è negativa.

Un'efficace gestione delle dipendenze con i pacchetti Salesforce consente ai team di sviluppo e manutenzione di:

• Integrazione più rapida e con accesso limitato all'ambiente nei nuovi progetti
• Sviluppare e testare rapidamente le modifiche
• Comprendere in che modo le funzionalità complesse devono essere fornite in impegni più piccoli e specifici
• Controllare le cadenze dei rilasci e ridurre le finestre di manutenzione/disattivazione dei rilasci del sistema
• Ritirare in modo prevedibile le modifiche avverse in qualsiasi ambiente

Le tecniche per la gestione delle dipendenze con Salesforce sono abbastanza semplici:

• Utilizzare messaggistica ed eventing per gestire agevoli passaggi di informazioni stateful o stateless tra i componenti.
• Utilizzare i tipi di metadati personalizzati per fornire informazioni dinamiche in fase di esecuzione e per supportare gli schemi di iniezione delle dipendenze.
• Fai usare agli sviluppatori Apex classi astratte o virtuali.

Alla fine, sarà necessario decidere gli schemi di progettazione consentiti nell'organizzazione durante lo sviluppo dichiarativo e programmatico. Le considerazioni più importanti (a livello architettonico) sono definire dove si desidera aggiungere più complessità ingegneristica per avere meno dipendenze e dove è necessario tollerare più dipendenze per semplificare i flussi di lavoro del generatore di app.

Quando si creano strategie di gestione delle dipendenze nei pacchetti, tenere presenti i due principi di organizzazione principali per le unità pacchetto: orizzontale e verticale.

• Confini orizzontali. Nei paradigmi orizzontali, le funzionalità che potrebbero essere necessarie a più di un pacchetto vengono astratte in un livello orizzontale. I livelli orizzontali diventano quindi l'origine delle funzionalità comuni e vi si accede tramite una dipendenza dichiarata. La riduzione al minimo delle funzionalità ridondanti tra i pacchetti è preferibile alla riduzione al minimo delle dipendenze.
• Confini verticali. I paradigmi verticali massimizzano l'isolamento e l'accoppiamento flessibile tra le parti del sistema. Le funzionalità condivise sono limitate e un lavoro simile potrebbe essere visualizzato tra le unità. Le dipendenze sono strettamente limitate, al fine di massimizzare l'isolamento tra le unità del pacchetto.

Tenere presente che non si tratta di una o più decisioni. È possibile combinare paradigmi verticali e orizzontali in base alle esigenze. Spesso, il modo più rapido per iniziare con un pacchetto è creare livelli di servizio orizzontali. Man mano che la scala e la complessità dell'adozione del pacchetto aumentano, l'astrazione di più unità verticali contribuirà a semplificare i processi di impostazione dell'ambiente complessi o l'orientamento degli sviluppatori.

Un sistema con due unità funzionali (A e B), ad esempio, può essere strutturato con dipendenze del pacchetto disposte in paradigmi ibridi verticali, orizzontali e verticali-orizzontali.

Indipendentemente dal paradigma di organizzazione dei pacchetti scelto, è necessario tenere presenti alcuni valori assoluti:

• Non duplicare i metadati tra i pacchetti. I metadati necessari per più di un pacchetto devono essere astratti in uno o più pacchetti dichiarati come dipendenze.
• Utilizzare le dipendenze incorporate dei metadati di Salesforce Platform. Per i generatori di app, i servizi integrati offerti da Salesforce Platform offrono numerose funzionalità che possono essere configurate rapidamente. Molti di questi servizi hanno dipendenze incorporate che li rendono difficili da astrarre in unità funzionali di basso livello. Per un determinato tipo di metadati, è necessario capire dove rientra lo spettro delle dipendenze incorporate e utilizzare questa comprensione per definire le catene di dipendenze del pacchetto. Non iniziare l'adozione dei pacchetti tentando di forzare l'accoppiamento in una parte della funzionalità standard della piattaforma con numerose dipendenze incorporate. Aggiungerà complessità (non valore) man mano che si raggiungono le funzionalità di ordine superiore. È anche un altro modo per cadere in anti-modelli standard e personalizzati. Inserire i metadati nei pacchetti dal basso (meno dipendenze) verso l'alto ed eseguire l'iterazione nel tempo.
• Attenzione alle catene di dipendenza. Evitare di creare catene di dipendenze dei pacchetti che richiedono agli sviluppatori di suddividere le modifiche in molti pacchetti diversi contemporaneamente.
• Pensare a cosa ha senso per il controllo sorgente. Esistono due modi di base per gestire i pacchetti nel controllo sorgente. Il primo è un singolo monorepo con pacchetti isolati all'interno di cartelle. Il secondo è costituito da più repository con pacchetti isolati nei propri repository. La gestione di ogni tipo di strategia di origine, a lungo termine, presenta delle complessità. In termini di onboarding degli sviluppatori, i confini verticali sono più efficienti in più paradigmi di repository. I confini orizzontali sono più comprensibili in un monorepo. Anche in questo caso, è possibile combinare le strategie man mano che l'architettura matura.

L'elenco di schemi e antischemi riportato di seguito mostra l'aspetto corretto (e inadeguato) della gestione delle dipendenze con i pacchetti Salesforce. È possibile utilizzarli per convalidare i progetti prima di crearli o identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per la gestione delle dipendenze, vedere Strumenti pertinenti per la composizione.

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri modelli per la possibilità di inserire pacchetti in Pattern & Anti-Pattern Explorer.

Aiutaci a mantenere Salesforce Well-Architected pertinente per te; partecipa al nostro sondaggio per fornire un feedback su questo contenuto e dirci cosa vorresti vedere dopo.