Comprendre la séparation des préoccupations

Objectifs de formation

Une fois cette unité terminée, vous pourrez :

• Expliquer la valeur commerciale de l'adoption de la séparation des préoccupations.
  
• Utiliser la SOC pour adapter votre solution aux modifications des exigences utilisateurs ou des technologies de la plate-forme.
  
• Appliquer la SOC au développement Salesforce.
  
• Déterminer quand appliquer la SOC.
  

Introduction

Les logiciels, comme les coupes de cheveux, sont souvent considérés comme des choses vivantes qui changent et évoluent au fil du temps. De l'amibe unicellulaire d'un programme de type « Bonjour tout le monde ! » à la complexité d'un logiciel d'entreprise, la gamme et la variété des formes de vie se retrouvent chez les logiciels. Les organismes complexes font évoluer des systèmes dans des buts spécialisés. Les squelettes, les muscles et les organes fonctionnent comme une unité, mais ils interagissent également avec d'autres systèmes au profit d'un tout.

La même chose est vraie des applications complexes d'entreprise. La séparation des diverses préoccupations en différents systèmes ou couches permet de simplifier le code à parcourir et à entretenir. Lorsque des modifications sont réalisées, les impacts et les régressions sur d'autres zones sont réduits et des programmes plus sains et plus adaptables peuvent évoluer.

Vidéo de démonstration Trail Together

Vous souhaitez être guidé pas à pas par un expert pendant que vous travaillez sur cette étape ? Regardez cette vidéo qui fait partie de la série Trail Together.

Séparation des préoccupations (SOC)

L'ours Cody dit souvent : « C’est loin du clavier qu’on écrit le meilleur code ». C’est une autre manière de dire qu'un bon code s'appuie sur une conception soignée et beaucoup d'anticipation. Gardez cette recommandation à l'esprit lorsque vous planifiez l'endroit où vous allez utiliser votre code. Le code est simple quand vous connaissez la voie à suivre !

Un code complexe devient incontrôlable si vous ne le partitionnez pas correctement. Lorsqu'un code est fortement entremêlé, il devient sujet aux erreurs, difficile à maintenir et à apprendre. Avez-vous déjà essayé de déboguer le code spaghetti de quelqu'un ? Et les problèmes empirent lorsque vous invitez de nouveaux développeurs. La création de modules de bibliothèque pour partager des calculs et des processus communs parmi les différentes parties de votre application est souvent la première étape de la réutilisation d'un code, ce qui est évidemment une bonne chose !

La SOC est-elle simplement une façon sophistiquée de parler de réutilisation du code ?

Oui... et non. La SOC nécessite des considérations en amont à propos de la plomberie interne de votre application, notamment les conventions de nommage des classes et les directives de codage. Vous souhaitez que cette planification perdure et soit en quelque sorte autodescriptive pour les autres. Un bon code doit raconter une histoire. L'approche ordinaire pour réutiliser un code consiste à déplacer des fragments de code dès qu'au moins deux zones en ont besoin. Le code est souvent simplement placé dans les classes MyUtil ou dans un autre entrepôt générique. Ce qui est une bonne chose, et très pratique pour un copier-coller !

Quels sont les avantages de la SOC ?

À un niveau élevé, les applications possèdent trois choses : du stockage, une logique et un moyen d’interaction à destination d'êtres humains, de créatures des bois ou d'autres applications. Lorsque vous séparez ces éléments, vous pouvez commencer par définir des couches au sein de votre application, chacune ayant son propre ensemble de préoccupations et de responsabilités vis-à-vis d'autres couches et de l'application générale. Une attention et une gestion soigneuses de ces couches est importante pour adopter la SOC.

• Évolution. Dans le temps, alors que la technologie, la compréhension et les exigences (fonctionnelles et techniques) évoluent, une couche peut avoir besoin d'être étendue, retravaillée ou même abandonnée. À titre d’exemple, voyons comment a évolué la technologie de l'interface utilisateur au cours des 10 dernières années. Combien de framework JavaScript pouvez-vous compter avant de vous endormir ?
  
• Gestion des impacts. La modification ou l'abandon d'une ou plusieurs couches ne doit pas indûment avoir une incidence sur les autres couches, à moins que ce ne soit intentionnel et lié aux spécifications.
  
• Rôles et responsabilités. Chaque couche possède sa propre responsabilité et ne doit pas tomber en dessous ni trop étendre cette responsabilité. Par exemple abandonner une technologie ou une bibliothèque client en faveur d'une autre ne signifie pas perdre de la logique métier car cela relève de la responsabilité d'une autre couche. Si les lignes de responsabilité deviennent floues, l'objectif et la valeur de la SOC s'en trouve érodés, ce qui n'est pas bon.
  

Salesforce Platform possède deux approches distinctes vis-à-vis du développement : le codage déclaratif (pointer-cliquer) et le codage traditionnel. Vous pouvez utiliser l'une ou l'autre méthode individuellement ou en conjonction. Les deux approches sont adaptées aux couches SOC standard, comme exposé ci-dessous.

Une présentation

• Déclaratif : présentations, pages d’enregistrement, flux, types d’enregistrement, formules, rapports, tableaux de bord
  
• Codage : Contrôleurs Apex, Visualforce, Composants Lightning
  

Couche logique métier

• Déclaratif : formule, flux, règles de validation, règles de partage, processus d’approbation
  
• Codage : services Apex, actions personnalisées Apex, Apex asynchrone
  

Couche d'accès aux données

• Déclaratif : chargeurs de données, Salesforce Connect
  
• Codage : SOQL, SOSL, API Salesforce
  

Couche base de données

• Déclaratif : Objets personnalisés, champs, relations, cumuls
  
• Codage : Déclencheurs Apex
  

Situations dans lesquelles vous n’avez pas besoin de la SOC dans Salesforce

L’un des avantages essentiels de Salesforce réside dans son modèle de développement déclaratif qui vous permet de créer des objets, champs, présentations, règles de validation, workflows, champs de formule et bien plus encore sans écrire une seule ligne de code. Le développement déclaratif est plus rapide et plus facile, et il met déjà en œuvre un degré de la SOC. Si votre application est fortement orientée données, et que vous pouvez fournir une grande partie de votre application de manière déclarative, vous n'avez pas à réinventer la roue : il vous suffit de l'utiliser !

Bien qu'il ne s'agisse pas de code, ce que vous pouvez réussir avec le développement déclaratif est encore très proche d'une couche d'architecture dans votre application, ce que nous aborderons plus en détail par la suite.

Situations dans lesquelles utiliser la SOC dans Salesforce

Si votre application est orientée processus ou si vous êtes poussé à mettre en œuvre des calculs, des validations plus complexes ou des expériences d'interface utilisateur plus riches, vous vous aventurerez sur les terres du code Apex. Salesforce permet de placer du code Apex dans de nombreux endroits, notamment au sein de déclencheurs, de classes comportant des méthodes @AuraEnabled, d’API, d’Apex par lot et de gestionnaires d’e-mails.

Vous pouvez réaliser un énorme investissement en développement et en test de code, mais c'est la logique métier que vous cherchez le plus à protéger. Nous allons explorer plus tard quelques recommandations relatives à l’écriture de logique métier, mais pour le moment, envisagez de recourir aux instances suivantes pour utiliser la SOC dans Salesforce.

• Remplacement ou ajout d'une autre IU à votre application : considérez la quantité de code dont vous avez besoin pour réécrire ou porter ce qui n'a rien à voir avec l'interface utilisateur, mais qui a une incidence sur les fonctionnalités d'insertion, de mises à jour, de validation et de calcul de votre application.
  
• Fourniture d'une API orientée public à votre logique : évaluez les parties de votre base de code existante que vous souhaiteriez appeler pour mettre en œuvre l'API. Vos méthodes @AuraEnabled constituent-elles une bonne base pour une API ? (La réponse est non.)
  
• Évolutivité de votre logique d'application via Apex par lot : si vous devez continuer à fournir une expérience interactive (pour des volumes plus restreints, via votre interface utilisateur existante, comment partageriez-vous la logique entre les deux pour vous assurer que l'utilisateur obtient des résultats cohérents, quelle que soit la taille ?
  
• Utilisation de logique complexe dans vos contrôleurs Visualforce ou vos méthodes @AuraEnabled : est-ce qu’une partie de votre code fait plus que transporter simplement des informations depuis et vers l’utilisateur ? Avec Visualforce et les Composants Lightning, vous pouvez partitionner votre code via modèle-vue-contrôleur (MVC), une forme de SOC pour le développement de clients. Toutefois, l'utilisation de contrôleurs pour la totalité de votre code ne garantit pas que vous suivez la SOC selon les termes de votre logique métier.
  
• Permettre aux nouveaux développeurs de s'y retrouver facilement dans votre base de code : de combien de temps un développeur a-t-il besoin pour apprendre où mettre le nouveau code et trouver le comportement existant ?
  

Selon l'endroit où vous avez écrit votre code, il est possible que vous soyez en bonne position pour vous attaquer à certains des scénarios ci-dessus. Sinon, ou si vous êtes juste curieux, les unités à venir vont éclairer vos prochaines réflexions. Le tableau suivant peut également vous aider à décider s'il convient d'utiliser ces modèles en fonction de la taille et de la portée de la solution que vous êtes en train de développer.

Ressources

• Séparation des préoccupations (Wikipédia)
• Modèles d’architecture d’entreprise de Martin Fowler