Modèles d’architecture

En savoir plus sur l’optimisation des ressources et des coûts bien archivée → Vos responsabilités en matière d’optimisation

Cette page fournit un guide de configuration complet pour les préoccupations architecturales, notamment les unités fonctionnelles, la séparation des préoccupations, la gestion de l’état, la gestion des API et la messagerie. Ces modèles déterminent la réussite à long terme des solutions en prenant des décisions de conception délibérées concernant les limites du service, les modèles d’accès aux données et les responsabilités des composants.

Modèles

Où chercher	À quoi ressemble le bien
Classes Apex	✅ Les classes de service suivent le principe de responsabilité unique avec des noms indiquant clairement le but (AccountService, OrderProcessor, InventoryManager). Chaque classe de service se concentre sur un domaine ou une capacité métier. Les méthodes des classes de service ont des responsabilités uniques et ciblées sur 20 lignes.
Déclencheurs	✅ Les déclencheurs délèguent à des classes de gestionnaire au lieu de contenir directement une logique métier. Modèle de gestionnaire de déclencheur utilisé de façon cohérente avec des noms de méthode clairs par contexte (handleBeforeInsert, handleAfterUpdate). Les classes Handler organisent la logique par événement déclencheur avec des responsabilités uniques par méthode.
Composants Web Lightning	✅ Les composants suivent le principe de responsabilité unique avec des interfaces de configuration claires. Chaque Composant Web Lightning se concentre sur une seule préoccupation de l’interface utilisateur (affichage des données, entrée utilisateur, navigation). Composants conçus pour la composition, pas pour des implémentations monolithiques.
Couche de service	✅ Les classes de service encapsulent une logique métier indépendante du point d’entrée (déclencheur, API, flux, lot). La même classe de service gère plusieurs contextes d’invocation sans duplication. La couche de service sépare les règles métiers des problèmes de présentation et d’accès aux données.
Composants réutilisables	✅ Composants conçus pour être réutilisés dans plusieurs projets et équipes. Le comportement piloté par la configuration en utilisant des types de métadonnées personnalisées permet de modifier le comportement sans déploiement de code. Les Actions invocables exposent la logique Apex sous forme de blocs de construction déclaratifs utilisables à partir d’un flux et d’une orchestration externe.

Anti-modèles

Où chercher	À quoi ressemble mal
Classe Dieu	⚠️ Évitez d’accumuler des responsabilités excessives dans une seule classe. Divisez les grandes classes (>500 lignes) en classes ciblées avec des responsabilités uniques. Réorganisez les classes lorsqu’elles gèrent plusieurs problèmes non liés (OrderProcessor ne doit pas également gérer l’envoi d’e-mails et les rapports).
Inquiétudes partagées	⚠️ Évitez de mélanger logique de déclenchement, règles métiers et accès aux données dans des classes uniques. Séparez la logique de présentation de la logique métier dans les contrôleurs. Gardez les préoccupations d’intégration séparées de la logique de domaine principale.
Logique de déclenchement dans les déclencheurs	⚠️ Évitez d’incorporer une logique métier directement dans des fichiers de déclencheur. N’utilisez jamais plus de 300 déclencheurs de ligne avec des conditions imbriquées. Déléguez toujours aux classes de gestionnaire avec une organisation claire des méthodes par contexte de déclencheur.

Modèles

Où chercher	À quoi ressemble le bien
Logique métier	✅ Règles métiers centralisées dans des classes de service, pas dispersées entre les déclencheurs, les contrôleurs et les classes par lot. Les classes de domaine encapsulent le comportement au niveau de l’enregistrement (validation, valeurs par défaut, valeurs dérivées) de façon cohérente, quelle que soit la méthode d’entrée des enregistrements dans le système. Logique réutilisée via la couche de service plutôt que dupliquée entre les points d’entrée.
Accès aux données	✅ Accès aux données abstrait derrière des classes de schéma de référentiel ou de sélecteur. Requêtes SOQL centralisées dans des classes de sélecteur (AccountSelector, OpportunitySelector) garantissant des listes de champs cohérentes et des clauses WHERE. Le modèle de référentiel permet de tester avec des sources de données fictives sans changer la logique métier.
Contrats d’interface	✅ Les composants communiquent via des interfaces explicites plutôt que des détails d’implémentation. Les interfaces Apex définissent les contrats entre les couches. La configuration des métadonnées personnalisées définit les limites du comportement. Les événements de plate-forme fournissent des contrats de messagerie entre les producteurs et les consommateurs.
Frontières du module	✅ Les contextes délimités définissent des limites de propriété claires pour les modèles de données et les règles métiers. Chaque module possède ses données, son automatisation et sa logique métier. Les modules interagissent via des API définies au lieu de partager directement des objets de base de données. La documentation identifie clairement l’équipe propriétaire des objets et des services.
Flux de dépendance	✅ Les dépendances circulent dans un sens (présentation → métier → données). La logique métier principale ne dépend d’aucun élément externe, permettant une évolution indépendante. Les problèmes d’infrastructure (consignation, mise en cache, API externes) dépendent de la logique métier à travers des interfaces, pas l’inverse.

Anti-modèles

Où chercher	À quoi ressemble mal
Duplication logique	⚠️ Évitez de dupliquer la logique métier entre les déclencheurs, les points de terminaison d’API et les classes par lot. Centralisez dans la couche de service et réutilisez à travers les points d’entrée. Chaque fois qu’une même règle métier est affichée dans plusieurs classes, extrayez vers un service partagé.
Accès aux données dispersé	⚠️ Évitez les requêtes SOQL dispersées dans les classes trigger, controller et batch avec des listes de champs et des clauses WHERE incohérentes. Centralisez les requêtes dans des classes de sélecteur afin de garantir des modèles cohérents et d’activer l’optimisation LDV à un emplacement unique.
Logique métier dans les déclencheurs	⚠️ Évitez les règles de validation, les calculs de champ et l’orchestration de workflow incorporés directement dans un code de déclencheur. Accéder à des classes de service ou des classes de domaine. Gardez les déclencheurs minces, concentrés uniquement sur la délégation à des gestionnaires appropriés.
Logique métier dans les contrôleurs	⚠️ Évitez les calculs complexes, la validation ou la manipulation de données dans les méthodes de contrôleur Aura/LWC. Les contrôleurs doivent orchestrer les appels à la couche de service, pas implémenter directement des règles métiers.
Dépendances circulaires	⚠️ Évitez les packages ou les classes avec des dépendances circulaires où A dépend de B et B dépend de A. Résolvez en extrayant les préoccupations partagées dans un module séparé, en inversant le sens des dépendances ou en utilisant une communication pilotée par l’événement pour rompre le couplage.

Modèles

Où chercher	À quoi ressemble le bien
Cache de la plate-forme (partition de l’organisation)	✅ Données de référence fréquemment accédées mises en cache dans la partition de l’organisation, y compris les références de métadonnées personnalisées, les valeurs de liste de sélection, les paramètres de configuration et les résultats calculés des opérations coûteuses. TTL par défaut configuré en fonction de la volatilité des données (heures pour les données de référence qui changent tous les mois, minutes pour la configuration fréquemment mise à jour). La stratégie de clé de cache évite les collisions entre différents types de données.
Cache de la plate-forme (partition de session)	✅ Préférences spécifiques à l’utilisateur, données de personnalisation calculées et état de session stocké dans le cache de la session. Cache de session non utilisé pour les données qui doivent être partagées entre les utilisateurs. La stratégie d’invalidation du cache gère correctement les mises à jour des préférences de l’utilisateur.
Service de données Lightning	✅ LDS fournit la mise en cache automatique des enregistrements côté client pour les composants Web Lightning. Les opérations CRUD standard utilisent LDS plutôt que des contrôleurs Apex personnalisés. LDS élimine les allers-retours de serveur redondants et fournit des mises à jour d’interface utilisateur optimistes. Les composants exploitent le cache LDS partagé à travers la page.
Types de métadonnées personnalisées	✅ Règles de configuration et de comportement stockées dans des types de métadonnées personnalisées plutôt que codées en dur dans des classes. Métadonnées personnalisées déployables entre les environnements via des ensembles de modifications ou un développement piloté par la source. Les modifications apportées aux métadonnées personnalisées ne nécessitent pas de cycle de déploiement complet. Mettez en cache les requêtes de métadonnées personnalisées dans Cache de la plate-forme pour les performances.

Anti-modèles

Où chercher	À quoi ressemble mal
Requête en boucle	⚠️ Évitez d’exécuter SOQL dans des boucles d’itération. Interrogez tous les enregistrements requis dans une instruction SOQL unique hors des boucles. Organisez les résultats dans Maps par ID parent pour la référence pendant l’itération. C’est l’anti-modèle Salesforce le plus courant.
Requêtes répétitives	⚠️ Évitez d’interroger plusieurs fois les mêmes métadonnées personnalisées, paramètres personnalisés ou données de référence par transaction. Interrogez une fois, mettez en cache dans Cache de la plate-forme ou variable statique de transaction, réutilisez entre les transactions.
Stratégie de cache manquante	⚠️ Évitez d’interroger à répétition les données de référence fréquemment accédées sans les mettre en cache. Implémentez le cache de la plate-forme pour les métadonnées personnalisées, la configuration et les résultats calculés. Définissez le TTL approprié en fonction de la volatilité des données.
Cache sans invalidation	⚠️ Évitez de mettre les données en cache sans prendre en compte la stratégie d’invalidation. Définissez le TTL de cache approprié pour mettre à jour la fréquence. Implémentez l’effacement manuel du cache lorsque les données sources changent si le TTL seul est insuffisant.
État de session non géré	⚠️ Évitez de supposer que l’état de session persiste dans les navigations de page sans vérification. Les composants Lightning doivent gérer l’actualisation de l’état au chargement de la page. Utilisez Lightning Data Service pour la synchronisation automatique des états.

Modèles

Où chercher	À quoi ressemble le bien
Planification de l’architecture de solution	✅ La planification de l’architecture est effectuée avant un investissement important dans l’élaboration, notamment l’analyse des exigences (fonctionnelles et non fonctionnelles), l’analyse des limites du gouverneur pour les volumes de données attendus, la sélection de modèles adaptés aux exigences et la conception de composants définissant les principaux composants et interfaces.
Sélection du modèle de conception	✅ Des modèles de conception Salesforce éprouvés appliqués de façon cohérente : Modèle de couche de service pour la réutilisation de la logique métier, Modèle de référentiel/sélecteur pour l’abstraction de l’accès aux données, Modèle de stratégie pour les algorithmes interchangeables, Modèle de domaine pour le comportement au niveau de l’enregistrement, Modèle de gestionnaire de déclencheur pour une organisation cohérente des déclencheurs.
Enregistrements de décision d’architecture	✅ Décisions architecturales importantes documentées dans les ADR stockés dans le contrôle de version. Les ADR capturent le contexte (moteurs métiers, contraintes techniques), la décision (ce qui a été choisi), les alternatives envisagées (pourquoi d’autres ont rejeté) et les conséquences (arbitrages, dette technique, déclencheurs de revisite).
Évaluation Élaborer par rapport à Acheter	✅ L’évaluation AppExchange précède les décisions de développement personnalisées en utilisant l’analyse du coût total de possession. Les critères d’évaluation comprennent la valeur stratégique (différenciateur de concurrence par rapport au produit de base), la comparaison du TCO (effort de construction, maintenance, coûts de mise à niveau), la complexité de l’intégration et le coût de sortie si la solution s’avère inadéquate.
Analyse des limites du gouverneur	✅ La planification architecturale identifie les limites du gouverneur qui limitent le plus la conception compte tenu des volumes de données et des modèles de transaction attendus. Transactions conçues pour consommer moins de 80 % d’une limite unique du gouverneur dans des conditions de pointe. Marge créée pour la croissance, les fonctionnalités futures et les modèles d’utilisation inattendus.
Évaluation des risques	✅ Risques techniques identifiés pour les approches architecturales qui repoussent les limites de la plate-forme. Stratégies d’atténuation définies pour chaque risque important. Le prototype ou le travail de validation de concept valide les hypothèses pour les approches techniques à haut risque avant l’engagement complet.

Anti-modèles

Où chercher	À quoi ressemble mal
Aucune planification	⚠️ Évitez de commencer à élaborer sans analyser les volumes de données, les implications des limites du gouverneur ou la sélection du modèle. L’atelier de planification de l’architecture devrait identifier les contraintes clés, sélectionner des modèles et valider par rapport aux limites du gouverneur avant le début de la construction.
Décisions non documentées	⚠️ Évitez les décisions architecturales prises en réunion sans capturer le contexte, la justification, les alternatives et les conséquences. Utilisez des enregistrements de décision d’architecture stockés dans le contrôle de version en préservant le contexte de décision pour les futurs membres de l’équipe.
Analyse Aucune construction par rapport à Achat	⚠️ Évitez d’élaborer des solutions personnalisées sans évaluation AppExchange. Évaluez les 3 à 5 principaux packages pertinents avant le développement personnalisé. Comparez le TCO, y compris les efforts d’implémentation, la maintenance, les coûts de mise à niveau et les coûts de sortie.
Sous-ingénierie	⚠️ Évitez de concevoir uniquement pour les volumes de données actuels sans projection de croissance. Projection de la croissance des données sur 2-3 ans. Concevez des modèles de requête avec une sélectivité validée par rapport à 5-10x les volumes actuels. Créer une marge architecturale pour la croissance.

Modèles

Où chercher	À quoi ressemble le bien
Forfaits gérés de deuxième génération (2GP)	✅ 2GP utilisé pour les nouveaux packages gérés nécessitant l’isolation de l’espace de noms, la distribution AppExchange et la protection IP. Workflow de développement piloté par la source avec le développement d’applications modulaires. Les dépendances de package gérées explicitement. Versions publiées avec la gestion des versions sémantiques.
Forfaits déverrouillés	✅ Packages déverrouillés utilisés pour des applications d’entreprise internes nécessitant une modularité sans contrainte d’espace de noms. Déploiement indépendant de packages sans artefact dépendant de l’organisation. Dépendances du package suivies pour l’ordre de déploiement approprié. Stratégie de gestion des versions définie pour les packages internes.
Frontières du module	✅ Définir des limites de propriété claires pour chaque package. Chaque package possède son modèle de données, ses règles métiers et son automatisation. Les packages interagissent via des interfaces définies plutôt que par un accès direct aux objets. La documentation identifie la propriété du package et les contrats inter-packages.