Modelli di architettura

Ulteriori informazioni sull’ottimizzazione di risorse e costi ben progettata → Le responsabilità dell’ottimizzazione

Questa pagina fornisce istruzioni complete sugli schemi per le problematiche architettoniche, tra cui unità funzionali, separazione delle problematiche, gestione dello stato, gestione API e messaggistica. Questi schemi determinano il successo delle soluzioni a lungo termine attraverso decisioni di progettazione deliberate sui confini del servizio, sugli schemi di accesso ai dati e sulle responsabilità dei componenti.

Schemi

Dove cercare	Che bell’aspetto
Classi Apex	✅ Le classi di servizio seguono il principio di responsabilità singola con nomi che indicano chiaramente lo scopo (AccountService, OrderProcessor, InventoryManager). Ogni classe di servizio si concentra su un dominio o una funzionalità aziendale. I metodi all’interno delle classi di servizio hanno responsabilità singole e mirate inferiori a 20 righe.
Trigger	✅ I trigger delegano alle classi handler anziché contenere direttamente la logica aziendale. Schema trigger handler utilizzato in modo coerente con nomi di metodi chiari in base al contesto (handleBeforeInsert, handleAfterUpdate). Le classi di handler organizzano la logica in base all’evento trigger con singole responsabilità per metodo.
Componenti Web Lightning	✅ I componenti seguono il principio di responsabilità singola con interfacce di scena chiare per la configurazione. Ogni LWC si concentra su un problema dell’interfaccia utente (visualizzazione dei dati, input dell’utente, navigazione). Componenti progettati per la composizione, non implementazioni monolitiche.
Livello di servizio	✅ Le classi di servizio incapsulano la logica aziendale indipendentemente dal punto di ingresso (trigger, API, flusso, batch). La stessa classe di servizio gestisce più contesti di chiamata senza duplicazioni. Il livello di servizio separa le regole aziendali dalle preoccupazioni relative alla presentazione e all’accesso ai dati.
Componenti riutilizzabili	✅ Componenti progettati per il riutilizzo in più progetti e team. Il comportamento basato sulla configurazione che utilizza tipi di metadati personalizzati abilita le modifiche del comportamento senza distribuzione di codice. Le azioni invocabili espongono la logica Apex come componenti base dichiarativi utilizzabili da Flusso e orchestrazione esterna.

Anti-schemi

Dove cercare	Che brutto aspetto
Classe di Dio	⚠️ Evitare di accumulare responsabilità eccessive in una singola classe. Suddividere le classi di grandi dimensioni (>500 righe) in classi mirate con responsabilità singole. Riorganizzare le classi quando gestiscono più problemi non correlati (OrderProcessor non deve gestire anche l’invio di email e la generazione di rapporti).
Preoccupazioni miste	⚠️ Evitare di mescolare logica dei trigger, regole aziendali e accesso ai dati in classi singole. Separare la logica di presentazione dalla logica aziendale nei controller. Tenere separati i problemi di integrazione dalla logica di dominio principale.
Logica dei trigger nei trigger	⚠️ Evitare di incorporare la logica aziendale direttamente nei file dei trigger. Non utilizzare mai più di 300 trigger di riga con condizionali nidificati. Delegare sempre le classi handler con un’organizzazione chiara del metodo in base al contesto del trigger.

Schemi

Dove cercare	Che bell’aspetto
Logica aziendale	✅ Regole aziendali centralizzate nelle classi di servizio, non sparse tra trigger, controller e classi batch. Le classi di dominio incapsulano il comportamento a livello di record (convalida, valori predefiniti, valori derivati) in modo coerente indipendentemente dal modo in cui i record entrano nel sistema. Logica riutilizzata tramite il livello di servizio anziché duplicata tra i punti di ingresso.
Accesso ai dati	✅ Accesso ai dati astratto dietro classi di repository o pattern selettore. Query SOQL centralizzate in classi selettore (AccountSelector, OpportunitySelector) che garantiscono elenchi di campi e clausole WHERE coerenti. Lo schema di repository consente di eseguire test con fonti di dati fittizie senza modificare la logica aziendale.
Contratti di interfaccia	✅ I componenti comunicano tramite interfacce esplicite anziché dettagli di implementazione. Le interfacce Apex definiscono i contratti tra i livelli. La configurazione dei metadati personalizzata definisce i limiti del comportamento. Gli eventi piattaforma forniscono contratti di messaggistica tra produttori e consumatori.
Confini modulo	✅ I contesti delimitati definiscono confini di proprietà chiari per i modelli di dati e le regole aziendali. Ogni modulo è titolare dei dati, dell’automazione e della logica aziendale. I moduli interagiscono tramite API definite anziché condividere direttamente gli oggetti di database. La documentazione identifica chiaramente quale team è titolare di quali oggetti e servizi.
Flusso di dipendenza	✅ Le dipendenze fluiscono in una direzione (presentazione → business → dati). La logica aziendale di base non dipende da nulla di esterno, abilitando un’evoluzione indipendente. I problemi di infrastruttura (registrazione, caching, API esterne) dipendono dalla logica aziendale tramite le interfacce, non viceversa.

Anti-schemi

Dove cercare	Che brutto aspetto
Duplicazione logica	⚠️ Evitare di duplicare la logica aziendale tra trigger, endpoint API e classi batch. Centralizzare nel livello di servizio e riutilizzare i punti di ingresso. Ogni volta che la stessa regola aziendale appare in più classi, estrarre in servizio condiviso.
Accesso ai dati sparso	⚠️ Evitare le query SOQL sparse in trigger, controller e classi batch con elenchi di campi e clausole WHERE incoerenti. Centralizzare le query in classi selettori per garantire schemi coerenti e abilitare l’ottimizzazione LDV in un’unica posizione.
Logica aziendale nei trigger	⚠️ Evitare le regole di convalida, i calcoli dei campi e l’orchestrazione del flusso di lavoro incorporati direttamente nel codice trigger. Passare a classi di servizio o di dominio. Mantenere sottili i trigger, concentrandosi solo sulla delega agli handler appropriati.
Logica aziendale nei controller	⚠️ Evitare calcoli complessi, convalida o manipolazione dei dati nei metodi di controllo Aura/LWC. I controller devono orchestrare le chiamate al livello di servizio, non implementare direttamente le regole aziendali.
Dipendenze circolari	⚠️ Evitare pacchetti o classi con dipendenze circolari in cui A dipende da B e B dipende da A. Risolvere estraendo le preoccupazioni condivise in un modulo separato, invertendo la direzione delle dipendenze o utilizzando la comunicazione basata sugli eventi per interrompere l’accoppiamento.

Schemi

Dove cercare	Che bell’aspetto
Cache piattaforma (partizione organizzazione)	✅ Dati di riferimento ad accesso frequente memorizzati nella cache della partizione dell’organizzazione, tra cui ricerche di metadati personalizzati, valori di elenchi di selezione, impostazioni di configurazione e risultati calcolati di operazioni costose. TTL predefinito configurato in base alla volatilità dei dati (ore per i dati di riferimento che cambiano ogni mese, minuti per le configurazioni aggiornate di frequente). La strategia della chiave cache evita le collisioni tra diversi tipi di dati.
Cache piattaforma (partizione sessione)	✅ preferenze specifiche dell’utente, dati di personalizzazione calcolati e stato limitato alla sessione memorizzati nella cache della sessione. Cache di sessione non utilizzata per i dati che devono essere condivisi tra gli utenti. La strategia di invalidamento della cache gestisce gli aggiornamenti delle preferenze utente in modo appropriato.
Servizio dati Lightning	✅ LDS fornisce il caching automatico dei record lato client per i componenti Web Lightning. Le operazioni CRUD standard utilizzano LDS anziché controller Apex personalizzati. LDS elimina i viaggi di andata e ritorno del server ridondanti e fornisce aggiornamenti ottimistici dell’interfaccia utente. I componenti sfruttano la cache LDS condivisa in tutta la pagina.
Tipi di metadati personalizzati	✅ regole di configurazione e comportamento memorizzate in tipi di metadati personalizzati anziché codificate nelle classi. Metadati personalizzati distribuibili in tutti gli ambienti tramite serie di modifiche o sviluppo basato sulla fonte. Le modifiche ai metadati personalizzati non richiedono un ciclo di distribuzione completo. Inserire nella cache dei metadati personalizzati le query nella cache piattaforma per le prestazioni.

Anti-schemi

Dove cercare	Che brutto aspetto
Query in loop	⚠️ Evitare di eseguire SOQL all’interno dei cicli di iterazione. Eseguire query su tutti i record necessari in un’unica istruzione SOQL all’esterno dei loop. Organizzare i risultati in Maps per ID controllante per la ricerca durante l’iterazione. Questo è l’anti-schema Salesforce più comune.
Query ripetitive	⚠️ Evitare di eseguire query sugli stessi metadati personalizzati, impostazioni personalizzate o dati di riferimento più volte per transazione. Eseguire una query una volta sola, memorizzare nella cache della piattaforma o nella variabile statica della transazione, riutilizzarla in tutta la transazione.
Strategia cache mancante	⚠️ Evitare di eseguire ripetutamente query sui dati di riferimento a cui si accede di frequente senza eseguire il caching. Implementare la cache piattaforma per i metadati personalizzati, la configurazione e i risultati calcolati. Definire un TTL appropriato in base alla volatilità dei dati.
Cache senza invalidazione	⚠️ Evitare il caching dei dati senza considerare la strategia di invalidazione. Definire il TTL della cache appropriato per aggiornare la frequenza. Implementare la cancellazione manuale della cache quando i dati di origine cambiano se il TTL da solo è insufficiente.
Stato sessione non gestito	⚠️ Evitare di presumere che lo stato della sessione persista nelle navigazioni delle pagine senza verifica. I componenti Lightning devono gestire l’aggiornamento dello stato al caricamento della pagina. Utilizzare Lightning Data Service per la sincronizzazione automatica dello stato.

Schemi

Dove cercare	Che bell’aspetto
Pianificazione dell’architettura delle soluzioni	✅ La pianificazione dell’architettura avviene prima di un investimento significativo nella creazione, che include l’analisi dei requisiti (funzionali e non), l’analisi del limite del governor per i volumi di dati previsti, la selezione dello schema appropriato ai requisiti e la progettazione dei componenti che definiscono i componenti e le interfacce principali.
Selezione del modello di progettazione	✅ Modelli di progettazione Salesforce collaudati applicati in modo coerente: Schema del livello di servizio per il riutilizzo della logica aziendale, Schema repository/selettore per l’astrazione dell’accesso ai dati, Schema strategico per gli algoritmi intercambiabili, Schema di dominio per il comportamento a livello di record, Schema trigger handler per un’organizzazione dei trigger coerente.
Record decisioni architettura	✅ Decisioni architettoniche significative documentate nelle ADR memorizzate nel controllo di versione. Gli ADR acquisiscono contesto (fattori trainanti dell’attività, vincoli tecnici), decisione (cosa è stato scelto), alternative considerate (perché altri hanno rifiutato) e conseguenze (compromessi, debito tecnico, fattori scatenanti di rivisitazione).
Valutazione build vs buy	✅ La valutazione AppExchange precede le decisioni di sviluppo personalizzate utilizzando l’analisi del costo totale di proprietà. I criteri di valutazione includono il valore strategico (differenziatore competitivo rispetto alle materie prime), il confronto del TCO (impegno di creazione, manutenzione, costi di aggiornamento), la complessità dell’integrazione e il costo di uscita se la soluzione si rivela inadeguata.
Analisi dei limiti dei governanti	✅ Pianificazione architettonica identifica il governor che limita maggiormente la progettazione dati i volumi di dati e gli schemi di transazione previsti. Transazioni progettate per consumare meno dell’80% del limite di un singolo governor in condizioni di picco. Margine creato per la crescita, le funzionalità future e gli schemi di utilizzo imprevisti.
Valutazione del rischio	✅ Rischi tecnici identificati per gli approcci architettonici che spingono i confini della piattaforma. Strategie di mitigazione definite per ogni rischio significativo. Il lavoro su prototipi o prove di fattibilità convalida le ipotesi per gli approcci tecnici ad alto rischio prima dell’impegno completo per la creazione.

Anti-schemi

Dove cercare	Che brutto aspetto
Nessuna pianificazione	⚠️ Evitare di iniziare la creazione senza analizzare i volumi di dati, le implicazioni del limite governor o la selezione dello schema. Il workshop di pianificazione dell’architettura dovrebbe identificare i vincoli chiave, selezionare gli schemi e convalidarli rispetto ai limiti del governor prima dell’inizio della creazione.
Decisioni non documentate	⚠️ Evitare le decisioni architettoniche prese nelle riunioni senza cogliere contesto, logica, alternative e conseguenze. Utilizzare i record decisione dell’architettura memorizzati nel controllo di versione conservando il contesto decisionale per i futuri membri del team.
Nessuna analisi build vs buy	⚠️ Evitare di creare soluzioni personalizzate senza valutazione AppExchange. Valutare i primi 3-5 pacchetti pertinenti prima dello sviluppo personalizzato. Confrontare il TCO, incluse le attività di implementazione, manutenzione, costi di aggiornamento e costi di uscita.
Sottoingegneria	⚠️ Evitare di progettare solo per i volumi di dati correnti senza proiezione di crescita. Proiettare la crescita dei dati in 2-3 anni. Progettare schemi di query con selettività convalidata rispetto ai volumi correnti 5-10x. Creare un margine architettonico per la crescita.

Schemi

Dove cercare	Che bell’aspetto
Pacchetti gestiti di seconda generazione (2GP)	✅ 2GP utilizzato per i nuovi pacchetti gestiti che richiedono l’isolamento dello spazio dei nomi, la distribuzione AppExchange e la protezione IP. Flusso di lavoro di sviluppo basato sulla fonte con sviluppo di applicazioni modulari. Dipendenze dei pacchetti gestite in modo esplicito. Versioni rilasciate con controllo semantico delle versioni.
Pacchetti sbloccati	✅ Pacchetti sbloccati utilizzati per applicazioni aziendali interne che richiedono modularità senza vincoli di spazio dei nomi. Distribuzione indipendente dei pacchetti senza artefatti dipendenti dall’organizzazione. Dipendenze dei pacchetti tracciate per un corretto ordinamento della distribuzione. Strategia di controllo delle versioni definita per i pacchetti interni.
Confini modulo	✅ Chiarire i confini di proprietà definiti per ogni pacchetto. Ogni pacchetto è titolare del modello di dati, delle regole aziendali e dell’automazione. I pacchetti interagiscono tramite interfacce definite anziché tramite l’accesso diretto agli oggetti. La documentazione identifica la proprietà dei pacchetti e i contratti tra pacchetti.