Découvrez ici nos planifications de mise à jour.

Les solutions composables s'ajustent rapidement et avec plus de stabilité. Un système conçu pour être composable est construit dans des unités significatives, ou blocs de construction, qui peuvent fonctionner gracieusement les uns avec les autres et peuvent être facilement échangés dans et hors service. L'intégration de la composition dans un système permet d'introduire de nouvelles fonctionnalités ou de supprimer une dette technique en refactorisant ou en réassemblant des unités individuelles d'un système. La composabilité permet des cycles de livraison et des versions plus rapides et plus prévisibles, car les équipes peuvent se concentrer sur l'élaboration et la livraison de fonctionnalités significatives avec de petites quantités de modifications.

Les systèmes composables permettent aux entreprises de s'adapter plus rapidement et avec plus de stabilité, que le stimulus soit interne à l'entreprise ou causé par des facteurs externes. La composabilité aide les systèmes à être plus résilients et peut aider à rendre les solutions et les modèles architecturaux plus intentionnels.

Vous pouvez rendre vos solutions Salesforce plus composables en élaborant trois habitudes clés : séparation des préoccupations, interopérabilité et empaquetage. Ci-dessous, vous pouvez voir la relation de ces habitudes de deux façons : pour une unité unique de dans un système composable, et à travers plusieurs unités dans un système composable.

Unité unique et composable :

Un système composable:

Concept fondamental du génie logiciel et de l'architecture système, la séparation des préoccupations consiste à identifier diverses préoccupations au sein d'un système plus large qui peut être séparé en unités modulaires. Pour parvenir à une forte séparation des préoccupations au sein d'un système, il faut créer des unités pertinentes pour la logique d'application et les fonctions dans l'ensemble du système. Les unités plus petites aident les équipes de livraison et de maintenance d'applications à comprendre comment et où apporter des modifications, en limitant au maximum les interruptions dans le système plus grand. Les unités plus petites indiquent également clairement comment et où orienter le travail en traitant la dette technique et contribuent à la lisibilité générale de votre système.

Vous pouvez mieux séparer les préoccupations dans votre organisation Salesforce en vous orientant vers les capacités métiers et l'état de gestion.

Pour les systèmes Salesforce, la meilleure approche pour séparer les préoccupations applique une perspective orientée métier afin d'identifier et d'organiser les unités (ou capacités) modulaires au sein du système. Ceci est différent d'une vue orientée vers l'ingénierie, qui identifie les unités en fonction de leur fonction technique. Une perspective orientée métier dans la séparation des préoccupations nécessite d'organiser le code et les personnalisations dans votre système en fonction du service qu'ils fournissent aux utilisateurs professionnels et professionnels. Adopter cette approche ne signifie pas ignorer le potentiel de fonctions techniques redondantes ou dupliquées dans un système. Cela signifie plutôt que les services techniques sont clairement mappés avec un principe d'organisation qui est finalement transparent pour l'entreprise.

S'orienter vers les capacités métiers permet de s'assurer que les transferts entre les équipes d'analyse métier et de découverte vers les équipes de livraison sont aussi simples que possible. Si les générateurs d'applications n'ont aucune idée de l'emplacement où leurs unités de travail sont mappées avec votre architecture composable, vous n'avez pas de paysage d'application composable. Les mappages imprécis entre l'état final requis par l'entreprise et les unités modulaires d'une organisation augmentent également les chances que des équipes de développement ou des fournisseurs construisent des fonctions redondantes dans le système.

Tenez compte des points suivants pour orienter les unités fonctionnelles vers les capacités commerciales :

• Commencez par les tâches à faire. Concentrez-vous sur les tâches à réaliser (JTBD) des utilisateurs et de l'entreprise elle-même. Lancée par Tony Ulwick, l'approche JTBD est centrée sur la compréhension du « travail », ou véritable objectif, que les gens tentent d'accomplir en utilisant un produit ou un service. C'est un niveau d'abstraction supérieur à celui des tâches associées au rôle des utilisateurs ou des étapes individuelles d'un processus métier. Par exemple, des tâches telles que les contrôles dupliqués et les validations d'adresses peuvent appartenir à une fonction d'ordre supérieur « établir une vue unique du client ». Lorsque vous avez une idée claire de ces capacités métier de niveau supérieur, vous pouvez commencer à mapper des parties de votre système avec elles.
• Orienter vers les capacités, pas vers les structures hiérarchiques. La hiérarchie interne de vos unités commerciales n'est pas un proxy pour des capacités significatives ou des tâches à réaliser. La hiérarchie interne de votre entreprise a un impact important sur les processus et les structures de l'équipe (sans parler des budgets). Ce sont des considérations logistiques importantes. Mais les besoins fonctionnels de l'entreprise fonctionnent à un niveau d'abstraction plus élevé que la logistique. Si vous créez un module pour servir une structure hiérarchique au lieu d'une fonction d'ordre supérieur, notez qu'il peut être nécessaire de prendre des mesures supplémentaires pour identifier la relation entre ce module et les capacités métiers.
• Soyez itératif. Commencez par établir un partenariat avec l'entreprise afin d'identifier les capacités qui pourraient fonctionner pour un produit minimum viable (MVP). Lorsque vous identifiez une capacité, commencez à élaborer ce MVP. Pendant l'élaboration, identifiez les processus, les métadonnées et les événements ou messages qui sont essentiels à l'unité fonctionnelle que vous créez. Identifiez tous les processus, métadonnées et événements ou messages qui sont des dépendances externes. À mesure que des unités plus fonctionnelles sont conçues, implémentez la gestion des API et la gestion des dépendances pour élaborer des unités qui fonctionnent bien les unes avec les autres (au lieu de construire des unités cloisonnées).

La liste des modèles et anti-modèles ci-dessous montre à quoi ressemble une orientation correcte (et mauvaise) de la fonction métier dans une solution Salesforce. Vous pouvez les utiliser pour valider vos conceptions avant de les élaborer, ou identifier les zones de votre système qui doivent être refactorisées.

Pour plus d'informations sur les outils disponibles dans Salesforce pour vous aider à mieux vous orienter vers les capacités métiers, consultez Outils pertinents pour Composable.

La gestion de l'État est centrée sur la circulation de l'information à travers un système à divers moments dans le temps. Une gestion efficace des états permet aux applications de gérer des flux de données ou des interactions complexes avec un minimum de résultats imprévus ou indéterminés. La gestion de l'état dans une organisation Salesforce modulaire nécessite d'élaborer des chemins clairs pour les flux logiques dans et entre les unités, ainsi que des chemins gracieux pour les comportements d'exécution imprévus. La gestion d'état permet de former des flux logiques cohérents à partir d'unités d'application Salesforce modulaires. Dans la plupart des cas, cela nécessite une interopérabilité pour structurer le flux d'informations entre les unités.

Les difficultés de gestion des états entre des unités faiblement couplées entraînent souvent un développement d'application monolithique dans Salesforce. Vous pouvez le voir dans les grands « monoflux », qui sont construits pour tenter d'orchestrer un processus complexe dans un flux singulier. Un autre exemple est celui des classes Apex massives, qui orchestrent des processus complexes à travers un code spaghetti, ou une longue série de méthodes à usage unique. Ces types d'architecture d'application rendent la refactorisation et le débogage difficiles et augmentent les temps d'intégration pour les nouveaux membres d'équipe ou fournisseurs. Ils réduisent également la valeur des applications livrées à l'entreprise, car les fonctionnalités ne sont pas réutilisables.

Tenez compte des points suivants pour gérer l'état dans une organisation Salesforce modulaire :

• Déterminez quand utiliser des schémas stateful par rapport à stateless. Les modèles Stateful conservent les informations dans tout un parcours d'exécution, pas les modèles sans état. Dans un système faiblement couplé, les modèles sans état permettent de refactoriser les composants plus rapidement et avec moins d'effets secondaires. Cependant, les modèles sans état d'âme ne sont pas adaptés à tous les cas d'utilisation. Si vous élaborez des composants pour des opérations sur les données, les modèles d'état peuvent faciliter l'intégrité et la cohérence des données dans vos systèmes. Utilisez un schéma avec état si votre composant remplit l'un des critères suivants :
  • La sensibilisation au placement dans un parcours d'exécution plus important est essentielle au comportement du composant
  • Le comportement du composant doit changer en fonction des résultats d'une action en aval (par exemple, il doit changer l'exécution en fonction des messages d'annulation/d'erreur/de réussite des composants en aval)
  • Le composant doit attendre les réponses d'un système externe ou en aval pour terminer son travail
• Créez des catégories pertinentes pour les informations importantes. État est un terme ambigu qui peut s'appliquer à un éventail d'informations si vaste et si vaste au sein d'une organisation Salesforce (et au-delà) qu'en soi, ce terme n'a presque aucun sens. Une première étape nécessaire à l'élaboration de modèles d'états est donc de créer des catégories significatives pour les parcours d'exécution d'états les plus importants (ou types de comportement d'états) dans votre système. Quelques catégories à prendre en compte :
  • Navigation et formulaires
  • Opérations de base de données
  • Opérations par lot et en masse
  • Erreurs
• Définissez les états associés aux données en termes de transactions de base de données. Les comportements intégrés de la plate-forme vont limiter la majorité des considérations d'état pour les données dans Salesforce. N'essayez pas de gérer ce comportement. Concevez pour et avec. Concevez des solutions qui réduisent ou éliminent la logique des transactions distribuées. (pour plus de détails, consultez traitement des données).
• Identifier les états qui se produisent dans (et entre) les unités fonctionnelles. En assemblant des unités fonctionnelles dans de plus grands systèmes, tenez compte du fait que vous mélangez le comportement des composants sans état et sans état, et évitez les combinaisons qui pourraient créer des boucles interminables ou des écarts dans le traitement.
• Définissez les transferts. Déterminez quels composants de schémas de messagerie ou d'événements vont utiliser pour transmettre des données relatives à l'état à une autre partie du système. Assurez-vous que vous sensibilisez vos composants aux transactions et à leur gestion. N'incluez aucune logique de transaction distribuée dans vos transferts.
• Créez des mappages entre vos diagrammes et états de processus. Les diagrammes de processus détaillent les étapes qui déplacent les informations à travers votre système à divers moments dans le temps. Un diagramme d'état montre les changements réels dans les informations (l'état). Utilisez la partie du pied de page des métadonnées des formes des diagrammes Salesforce pour capturer l'évolution de l'état des informations à chaque étape de votre processus. Si vous séparez les diagrammes de processus et les diagrammes d'état, assurez-vous de les lier. Il ne faut pas confondre ce concept avec la capture de l'état actuel et futur des processus ou des paysages du système pendant la conception et la mise en oeuvre, car il ne s'agit pas de l'information qui circule dans le système.

La liste des modèles et anti-modèles ci-dessous montre à quoi ressemble une bonne (et mauvaise) gestion de l'état dans une solution Salesforce. Vous pouvez les utiliser pour valider vos conceptions avant de les élaborer, ou identifier les emplacements de votre système qui doivent être refactorisés.

Pour plus d'informations sur les outils Salesforce de gestion des états, consultez Outils pertinents pour Composable.

Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier.

✨ Découvrez d'autres modèles de séparation des préoccupations dans l'Explorateur de modèle et anti-modèle.

Dans un système conçu pour l'interopérabilité, les composants peuvent échanger des informations et fonctionner ensemble efficacement. L'interopérabilité est essentielle pour rendre un système modulaire composable plutôt que cloisonné. L'interopérabilité peut s'avérer difficile à atteindre dans un système peu couplé. Vous devez établir des normes pour des méthodes d’intégration cohérentes qui ne compromettent pas l’indépendance entre les unités et la séparation des préoccupations globales à travers le système.

L'interopérabilité impacte également la qualité de vos expériences utilisateur. Vos utilisateurs s'attendent à ce que les données créées dans une zone (par exemple les informations sur les commandes) puissent être utilisées dans une autre (par exemple les campagnes marketing), et vos générateurs s'attendent à ce que s'ils apprennent à faire quelque chose (par exemple élaborer un flux ou s'authentifier à une API), ils trouvent que les techniques familières fonctionnent lorsqu'ils passent au problème suivant. Ne pas concevoir pour l'interopérabilité entraînera des architectures redondantes, des données répliquées, des processus inefficaces et des coûts de développement et de support accrus.

Vous pouvez créer l'interopérabilité dans des systèmes modulaires avec la messagerie et les événements, ainsi qu'avec la gestion des API.

Les messages et les événements sont deux façons d'activer les composants à travers un système pour envoyer et recevoir des informations. En termes de contenu qu'ils peuvent véhiculer, les événements et les messages sont similaires. Une différence importante est le comportement de l'expéditeur. Généralement, un composant qui envoie un message envoie des données à une destination spécifique et attend une réponse du destinataire. Par contre, un composant émet un événement lorsqu'un événement s'est produit. Il n'y a pas de destination spécifique, ni d'attente de réponse. Ces différences de comportement supportent différents modèles de communication. Les messages prennent en charge les modèles de communication sans état et les événements prennent en charge les modèles de communication sans état. (Voir Gestion de l'État pour plus d'informations sur cette distinction.)

Il est important d'aligner les équipes sur les protocoles et les cas d'utilisation pour la messagerie et les événements. Des normes imprécises peuvent entraîner une combinaison de modèles dans votre système, entraînant :

• Problèmes de performance et d'évolutivité lorsque des modèles incorrects sont appliqués à un cas d'utilisation spécifique
• Traitement incohérent qui rend le système instable pour les utilisateurs
• Des temps de dépannage plus longs et des processus de maintenance plus complexes

Tenez compte des points suivants lors de la conception de messages et d'événements pour créer des structures plus vaguement couplées dans votre organisation Salesforce :

• Identifiez les cas d'utilisation de synchronisation et d'asynchronie. Le concours complet permet des communications vaguement couplées, sans état et asynchrones à travers un système. La messagerie permet des modèles de communication plus étroitement contrôlés, précis et synchrones. Lorsque vous choisissez d'utiliser des messages ou des événements, vous devez déterminer si votre communication doit être synchrone (et potentiellement bloquante) par rapport à asynchrone et non bloquante.
• Définissez soigneusement les structures de données. La structure de l'information que les composants transmettent entre eux est un élément important pour maintenir un système faiblement couplé gérable et cohérent. (pour plus d'informations, consultez Gestion des API). Une considération clé lors de la conception d'un message ou d'un événement est la fréquence à laquelle la structure de l'information doit changer. Une fois la structure d'un message ou d'un événement définie et implémentée dans votre système, il peut être difficile de gérer les mises à jour, en particulier si l'événement ou le message est déjà utilisé pour envoyer des informations à un système externe.
• Messages de taille correcte. En général, il est recommandé de limiter la taille des messages. Cependant, il existe également un équilibre entre la taille et le volume des messages. Les systèmes peuvent traiter plus rapidement de petites quantités de données. L'acte de traitement entraîne des frais généraux supplémentaires, car les destinataires doivent déballer, interpréter et déterminer ce qu'ils doivent faire avec les informations qu'ils ont reçues. Ces étapes peuvent prendre un temps négligeable, mais elles peuvent s'accumuler et créer un fardeau pour les systèmes à grande échelle. Évitez les conceptions qui nécessitent que les composants du système traitent successivement de nombreux petits messages pour réaliser un travail. Pour adapter la taille de vos messages, pensez à concevoir des composants en aval avec le minimum de données nécessaires pour traiter et agir avec succès sur la base des informations qu'ils ont envoyées, sans supposer également que chaque composant en aval sera capable de demander ou de traiter de nombreux messages de suivi.
• Conception évolutive. Des composants faiblement couplés peuvent faciliter l'adaptation de votre architecture. L'élimination des dépendances inter-composants permet aux équipes d'améliorer les performances ou l'évolutivité de n'importe quel composant individuel avec un minimum d'effets sur les autres. Cependant, les composants faiblement couplés introduisent également une complexité importante dans votre architecture à l'échelle (notamment en ce qui concerne l'état de gestion). Identifiez les processus qui doivent avoir une logique ou des dépendances plus étroitement couplées pour des raisons d'expérience utilisateur ou d'intégrité des données valides, et n'essayez pas d'introduire des modèles basés sur l'asynchronisme/l'événement dans ces processus. Utilisez à la place des modèles basés sur la synchronisation/les messages et un traitement approprié des erreurs.

La liste des modèles et anti-modèles ci-dessous montre à quoi ressemblent les messages et événements appropriés (et médiocres) dans une solution Salesforce. Vous pouvez les utiliser pour valider vos conceptions avant de les élaborer, ou identifier les emplacements de votre système qui doivent être refactorisés.

Pour plus d'informations sur les outils de messagerie et d'événementiel Salesforce, consultez Outils pertinents pour Composable. Pour plus d'informations sur le choix d'un modèle ou d'un outil de concours complet pour un cas d'utilisation donné, consultez le Architect’s Guide to Event-Driven Architecture with Salesforce.

L'élaboration d'une interface de programmation d'application (API) de gestion appropriée dans une solution Salesforce permet aux composants individuels de votre système de suivre des modèles de communication prévisibles. Salesforce fournit des API intégrées et sécurisées à utiliser pour communiquer avec des systèmes extérieurs à Salesforce. (pour plus d'informations sur les API Salesforce Platform, consultez Bases de l'architecture).

Une gestion efficace des API dans les solutions Salesforce est essentielle pour élaborer des architectures véritablement composables. Il permet aux composants d'une organisation Salesforce d'envoyer et de recevoir efficacement des informations. Il permet également aux générateurs de solutions de suivre des protocoles clairs pour la communication des composants qu'ils élaborent avec les autres composants du système, et les aide à identifier rapidement les implémentations incorrectes. De plus, il permet aux concepteurs de solutions de se concentrer plus étroitement sur le composant particulier qu'ils élaborent ou refactorisent, ce qui augmente la productivité et la qualité.

La gestion des API au niveau de l'entreprise est une rubrique distincte, qui est plus efficace avec un outil complet de gestion des API. (pour plus d'informations sur la perspective MuleSoft à ce sujet, consultez Qu'est-ce que la Gestion des API ?).

Tenez compte des points suivants pour élaborer des capacités de gestion d'API dans vos solutions Salesforce :

• Considérez les API comme des modèles prévisibles ou des contrats de communication. Le type de données des variables d'entrée ou de sortie, les noms des variables, les informations qui doivent (ou non) apparaître dans un schéma donné, voilà les clés d'une gestion efficace des API. Ces définitions doivent figurer dans vos normes de conception, et les équipes doivent pouvoir déterminer comment ces définitions ont été implémentées dans des parties particulières de votre système via votre documentation. Une façon d'examiner les difficultés de fusion des modifications d'un nouveau développement dans un environnement d'intégration est de les considérer comme une preuve de l'emplacement où vous avez mal implémenté les communications d'API (ou peut-être aucune définition d'API du tout).

• Ne limitez pas votre réflexion sur les API à coder exclusivement. Ce qui définit une API dans ce contexte est la cohérence des structures et des variables de message dans ce message. Tant que cette cohérence est maintenue, une API peut être implémentée dans un code ainsi que dans des personnalisations déclaratives, telles que des flux modulaires lancés automatiquement (ou déclenchés par un événement de plate-forme), ou même des modèles de flux. Basez vos décisions sur les éléments à définir dans le code par rapport aux flux non pas sur l'implémentation de l'API, mais plutôt sur la capacité et la testabilité du package.

• Simplifiez votre cycle de vie et la gestion des versions. Comme toutes les parties du développement d'applications, les API ont un cycle de vie : définir, élaborer, tester, déployer et maintenir (y compris retirer). Les API Salesforce Platform publient plusieurs versions par année civile, en raison du cycle de publication rapide de la plate-forme. (pour plus d'informations sur ce comportement, consultez Bases de l'architecture Salesforce). Cela signifie que les API de plate-forme ont un cycle de vie assez complexe, car plusieurs versions d'une API particulière doivent être conservées et disponibles pour les clients de Salesforce. Ce niveau de complexité est approprié pour les cas d'utilisation PaaS, mais il est probablement inutile pour vos architectures de solutions sur plate-forme (voir : Readablility anti-patterns). Mettez l'accent sur la définition d'un objectif clair pour une API (par exemple, le traitement des erreurs) et des définitions de base claires. Essayez d'avoir une seule version de chaque API.

• Rendez vos API accessibles, accessibles et gérables. Documentez vos API afin de permettre aux consommateurs potentiels de trouver aisément les API disponibles pour s'y connecter. Les API doivent fonctionner correctement dans un paysage de capacités.

• Soyez itératif. Concentrez-vous sur la définition et l'implémentation d'une seule API interne à la fois. Vous pouvez ainsi vous concentrer sur l'itération rapide de la définition d'API, trouver le formulaire approprié pour votre unique version prise en charge et établir les meilleures pratiques à partir de l'expérience d'implémentation.

La liste des modèles et anti-modèles ci-dessous montre à quoi ressemble une bonne (et mauvaise) gestion d'API dans une solution Salesforce. Vous pouvez les utiliser pour valider vos conceptions avant de les élaborer, ou identifier les zones de votre système qui doivent être refactorisées.

Pour plus d'informations sur les outils disponibles dans Salesforce pour renforcer l'interopérabilité, consultez Outils pertinents pour Composable.

Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier.

✨ Découvrez d'autres modèles d'interopérabilité dans l'explorateur Pattern & Anti-Pattern.

La création d'un package dans une organisation Salesforce signifie que les fonctionnalités de l'organisation proviennent d'unités qui peuvent être développées et déployées indépendamment et de façon fiable, sous forme de packages. Idéalement, ces unités sont définies comme un type de package de deuxième génération (un package déverrouillé ou un package géré pour les éditeurs de logiciels). Remarque : Les solutions bien conçues utilisent exclusivement ces types de package. Par conséquent, les packages gérés de première génération ne sont pas traités ici.

Définir la séparation des préoccupations et créer des unités fonctionnelles dans une organisation Salesforce est une chose. Il est également important de démêler et de gérer les dépendances de façon suffisamment claire pour réussir la version de ces unités en tant qu'artefacts de package. Pour atteindre ce niveau de stabilité et d'isolation des métadonnées, il faut un niveau de maturité DevOps (et architecturale) important. Il accélère également le temps de développement, améliore l'expérience du générateur d'applications, et apporte prévisibilité et contrôle dans les versions et la gestion des versions. Les organisations ne seront pas toutes capables de prendre en charge l'infrastructure requise pour définir, gérer et développer des packages efficaces. Cependant, l'objectif ultime de presque toutes les organisations Salesforce devrait être d'obtenir la possibilité d'empaqueter.

Vous pouvez élaborer des packages dans vos solutions Salesforce en vous concentrant sur le couplage lâche et la gestion des dépendances.

Dans un système avec couplage lâche, les pièces individuelles ne sont pas fortement liées les unes aux autres. De nombreux avantages d'un système composable proviennent d'un couplage lâche. Dans les systèmes empaquetables, la réalisation d'un couplage lâche entre les packages (et l'installation d'organisations) vous permettra d'avoir des packages bien définis et des cycles de développement plus productifs pour les équipes qui travaillent avec des packages.

Sur Salesforce Platform, vous pouvez élaborer des packages étroitement couplés à une organisation particulière. Cette capacité est utile pour définir des unités fonctionnelles et expérimenter une bonne séparation des préoccupations dans votre organisation, à mesure que vous progressez dans la maturité de l'empaquetage. Cependant, si vous choisissez cette approche, vous ne bénéficierez que de quelques avantages des métadonnées véritablement empaquetables, notamment le développement piloté par la source, la possibilité d'utiliser la gestion des versions et la stabilité des artefacts. À la place, vous allez probablement continuer à éprouver les inconvénients d'un système étroitement couplé, y compris:

• Points de défaillance uniques entraînant des pannes et des problèmes de performance
• Déploiements lents et imprévisibles
• Cycles de débogage et de dépannage difficiles et complexes
• Problèmes d'échelle et de performance

L'objectif final de tout système Salesforce empaquetable est de coupler des packages vagues.

Tenez compte des points suivants pour séparer vos métadonnées Salesforce en packages efficaces :

• Quelles personnalisations sont les données par rapport aux métadonnées ? En ce qui concerne l'empaquetage, Salesforce Platform traite les données et les métadonnées très différemment. Il est important de comprendre quelles fonctionnalités de votre organisation sont des métadonnées ou données. Vous ne pouvez inclure des données dans aucune unité empaquetée. Lorsque vous choisissez où commencer à extraire la fonctionnalité dans une unité empaquetée, vos équipes doivent déterminer si les personnalisations stockées en tant que données doivent être exclues du package ou refactorisées dans une implémentation basée sur des métadonnées.
• L'impact de l'empaquetage sur les équipes. Une réalité logistique de l'empaquetage Salesforce est qu'une grande partie du travail de production et de publication d'une version de package nécessite une compétence avec les technologies Salesforce CLI et/ou CI/CD. Cela signifie que les personnalisations à faible code et par programmation nécessitent du temps et de l'attention de la part d'une personne capable de travailler avec la technologie DevOps associée au package. Selon la façon dont votre équipe gère la livraison de fonctionnalités, l'adoption de packages peut entraîner des ralentissements ou des blocages importants pour différentes équipes d'une organisation. Vous devrez déterminer si les équipes seront en mesure de gérer la livraison de fonctionnalités via l'empaquetage, et établir un plan pour combler les lacunes en compétences ou en personnel. Les solutions peuvent inclure l'adoption d'une programmation couplée ou l'implémentation de tâches CI/CD pour des environnements de développement.
• Comment l'emballage va changer les stratégies environnementales Dans un cycle de vie de développement piloté par le package, le travail précoce doit être effectué dans les organisations tests. Ces environnements de développement temporaires, pilotés par la source, permettent des cycles plus rapides et plus itératifs. Ils prennent également en charge des contrôles d'accès à l'environnement plus précis pour vos équipes de développement et une plus grande isolation de la production. Plus vos packages sont dépendants de métadonnées non empaquetées ou de données qui existent uniquement dans un environnement sandbox ou de production, moins les équipes sont susceptibles d'utiliser des organisations tests. Vous pouvez activer le suivi de la source dans des organisations sandbox afin de permettre des modèles de développement pilotés par la source dans des environnements d'organisation non tests, mais vos équipes de développement ne bénéficieront pas de la vitesse et de la vélocité itératives des organisations tests.
• Comment les versions de package sont associées aux versions. Planifiez la fréquence et le stade de développement de la gestion des versions du package. Les demandes de version de package sont limitées (par organisation) sur une base glissante de 24 heures. La meilleure pratique générale consiste à mettre en version un package uniquement lorsque vous êtes sûr qu'aucun contenu du package ne doit changer. L'idéal est de provisionner des versions de package une fois les processus d'assurance qualité terminés. Ne permettez pas aux équipes de développement d'utiliser la réussite ou l'échec des requêtes de création de packages comme « test » de la qualité de la définition des limites des packages. Il existe plusieurs façons de procéder sans essayer de mettre en version un artefact de package.
• Ce que l'état final idéal devrait soutenir. La stratégie d'empaquetage idéale permet des versions Salesforce contrôlées et stables qui peuvent être développées et livrées rapidement. La définition d'un nombre excessif de packages dans votre organisation peut générer de nouveaux types de complexité et de blocage pour les équipes de développement. Une organisation trop modularisée peut également entraîner des versions lentes et difficiles. Commencez par élaborer et publier quelques versions d'un package unique et pertinent. Dérivez des packages de suivi de façon incrémentielle. Arrêtez d'introduire des packages lorsque vous avez une cadence de publication qui sert bien votre activité. Refactorisez les packages au fil du temps, si les besoins métiers changent ou si la qualité de la version diminue. L'état final idéal du package est subjectif.

Quelle que soit la façon dont vous choisissez de définir vos packages, vous ne réussirez à mettre en version un package faiblement couplé qu'avec une gestion des dépendances efficace.

La liste des modèles et anti-modèles ci-dessous montre à quoi ressemble le couplage lâche correct (et médiocre) pour l'empaquetage Salesforce. Vous pouvez les utiliser pour valider vos conceptions avant de les élaborer, ou identifier les zones de votre système qui doivent être refactorisées.

Pour plus d'informations sur les outils Salesforce qui facilitent l'élaboration de packages, consultez Outils pertinents pour Composable.

Dans le contexte d'une solution Salesforce, la gestion des dépendances consiste à identifier et à structurer les relations entre les métadonnées de vos packages et les métadonnées des organisations dans lesquelles ces packages seront installés. La gestion des dépendances est un élément clé du développement d'artefacts de package stables.

Les dépendances peuvent être en contradiction avec les efforts déployés pour créer des unités fonctionnelles parfaitement séparées et peu couplées. Dans un état d'ingénierie idéal, un système faiblement couplé n'a aucune dépendance entre les unités. Dans le monde réel, cependant, l'élimination de toutes les dépendances n'est pas pratique.

Souvent, l'équilibre entre la lisibilité des systèmes et l'utilisation d'unités fonctionnelles conviviales nécessite un compromis en termes d'isolation parfaite entre les unités d'un système. Plus pragmatiquement, les services de base fournis par la fonctionnalité standard de Salesforce Platform créent des dépendances clés et nettes pour n'importe quelle solution Salesforce. De nombreux avantages intégrés en matière d'évolutivité, de performance et de sécurité découlent de leur intégration profonde à la plate-forme. Lors de la conception de solutions Salesforce empaquetables, il est important de se rappeler que les dépendances de package ne sont pas intrinsèquement mauvaises. Une mauvaise gestion de la dépendance est mauvaise.

Une gestion efficace des dépendances avec le package Salesforce permet aux équipes de développement et de maintenance de :

• Accélération de l'intégration à de nouveaux projets et accès limité à l'environnement
• Développer et tester rapidement des modifications
• Comprendre comment les fonctionnalités complexes doivent être fournies dans des engagements plus petits et spécifiques
• Contrôler les cadences de publication et réduire les fenêtres de maintenance/d'arrêt de version du système
• Annuler de façon prévisible les modifications défavorables dans n'importe quel environnement

Les techniques de gestion des dépendances avec Salesforce sont assez simples :

• Utilisez la messagerie et les événements pour gérer les transferts gracieux d'informations avec ou sans statut entre les composants.
• Utilisez des types de métadonnées personnalisées pour fournir des informations d'exécution dynamiques et prendre en charge les modèles d'injection de dépendance.
• Demandez aux développeurs Apex d'utiliser des classes abstraites ou virtuelles.

Au final, vous devrez choisir les modèles de conception autorisés dans votre organisation à travers le développement déclaratif et programmatique. Les considérations les plus importantes (sur le plan architectural) sont de définir où vous souhaitez ajouter plus de complexité d'ingénierie afin d'avoir moins de dépendances, et où vous devez tolérer plus de dépendances pour simplifier les workflows du générateur d'applications.

En élaborant des stratégies de gestion des dépendances dans vos packages, tenez compte des deux principaux principes d'organisation des unités de package : horizontal et vertical.

• Frontières horizontales. Dans les paradigmes horizontaux, les fonctionnalités qui peuvent être nécessaires à plusieurs packages sont abstraites dans une couche horizontale. Les couches horizontales deviennent alors la source de fonctionnalités communes, et sont accédées via une dépendance déclarée. La réduction des fonctionnalités redondantes entre les packages est préférée à la réduction des dépendances.
• Frontières verticales. Les paradigmes verticaux maximisent l'isolement et le couplage lâche entre les parties du système. Les fonctionnalités partagées sont limitées et un travail similaire peut être affiché entre les unités. Les dépendances sont strictement limitées, afin de maximiser l'isolation entre les unités de package.

Notez qu'il ne s'agit pas d'une décision ou d'une décision. Vous pouvez combiner des paradigmes verticaux et horizontaux si nécessaire. Souvent, la méthode la plus rapide pour commencer avec un package est de créer des couches de service horizontales. À mesure que l'échelle et la complexité de l'adoption de votre package augmentent, l'abstraction d'unités verticales supplémentaires simplifie les processus de configuration d'environnement complexes ou l'intégration des développeurs.

Un système avec deux unités fonctionnelles (A et B), par exemple, peut être structuré avec des dépendances de package organisées en paradigmes hybrides verticaux, horizontaux et verticaux-horizontaux.

Quel que soit le paradigme d'organisation du package que vous choisissez, il y a quelques absolus à garder à l'esprit :

• Ne dupliquez pas les métadonnées entre les packages. Les métadonnées requises par plusieurs packages doivent être extraites dans un ou plusieurs packages déclarés en tant que dépendances.
• Utilisez les dépendances intégrées des métadonnées Salesforce Platform. Pour les générateurs d'applications, les services intégrés offerts par Salesforce Platform offrent de nombreuses fonctionnalités qui peuvent être configurées rapidement. Beaucoup de ces services ont des dépendances intégrées qui les rendent difficiles à extraire dans des unités fonctionnelles de bas niveau. Pour un type de métadonnées donné, vous devez comprendre sa position dans le spectre des dépendances intégrées et utiliser cette compréhension pour définir vos chaînes de dépendance de package. Ne commencez pas à adopter un package en essayant de forcer le couplage libre dans une fonctionnalité de plate-forme standard avec de nombreuses dépendances intégrées. Elle ajoutera de la complexité (pas de la valeur) lorsque vous atteindrez des capacités d'ordre supérieur. C'est aussi une autre façon de tomber dans les anti-modèles standards par rapport aux modèles personnalisés. Empaquetez les métadonnées depuis le bas (dépendances les plus faibles) vers le haut, puis itérez au fil du temps.
• Attention à vos chaînes de dépendance. Évitez de créer des chaînes de dépendance de package qui obligeront les développeurs à diviser leurs modifications en plusieurs packages à la fois.
• Réfléchissez à ce qui est logique pour le contrôle de la source. Il existe deux méthodes de base pour gérer vos packages dans le contrôle du code source. Le premier est un monorepo unique avec des packages isolés dans des dossiers. Le deuxième est le repos multiple avec des packages isolés dans leur propre repos. La gestion à long terme de chaque type de stratégie source est complexe. En termes d'intégration des développeurs, les frontières verticales sont plus efficaces dans plusieurs paradigmes de référentiel. Les frontières horizontales sont plus compréhensibles dans un monorepo. Là encore, vous pouvez combiner et mapper des stratégies à mesure que votre architecture mûrit.

La liste des modèles et anti-modèles ci-dessous montre à quoi ressemble une gestion correcte (et médiocre) des dépendances avec les packages Salesforce. Vous pouvez les utiliser pour valider vos conceptions avant de les élaborer, ou identifier les zones de votre système qui doivent être refactorisées.

Pour plus d'informations sur les outils Salesforce de gestion des dépendances, consultez Outils pertinents pour Composable.

Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier.

✨ Découvrez d'autres modèles d'empaquetage dans l'Explorateur de modèle et anti-modèle.

Aidez-nous à garder Salesforce Well-Architected pertinent pour vous ; répondez à notre sondage pour nous faire part de vos commentaires sur ce contenu et nous dire ce que vous souhaitez voir ensuite.