Architecture logicielle software-architecture
Conception pour les mises à niveau design-for-upgrades
Lors de l’extension de comportements prêts à l’emploi, il convient de garder à l’esprit les mises à niveau. Appliquez toujours des personnalisations dans le répertoire /apps et superposez-les au-dessus des nœuds correspondants dans le répertoire /libs ou utilisez sling:resourceSuperType pour étendre le comportement standard. Bien que quelques modifications puissent s’avérer nécessaires pour la prise en charge d’une nouvelle version d’AEM, cette dernière ne devrait normalement pas écraser vos personnalisations si cette pratique est observée.
Réutilisez les modèles et les composants dans la mesure du possible reuse-template-and-components-when-possible
Outre une maintenance plus simple du code, cela permettra au site de conserver une interface plus cohérente. Lorsqu’un nouveau modèle est nécessaire, veillez à l’étendre à partir d’un modèle de base partagé, de sorte que les exigences globales, telles que l’inclusion de clientlib, puissent être codées à un seul endroit. Lorsqu’un nouveau composant est nécessaire, identifiez les possibilités d’extension depuis un composant existant.
Créez des conceptions de modèles design-template-designs
Définir les composants qui peuvent être inclus dans chaque système de paragraphes sur la page permet de conserver l’homogénéité d’aspect et d’utilisation du site. En limitant l’accès à la conception sur les pages, des « super auteurs » peuvent être autorisés à modifier les composants autorisés par page sans l’intervention de l’équipe de développement, tout en s’assurant que les autres auteurs respectent les normes de l’entreprise.
Développement d’une architecture SOLID develop-a-solid-architecture
SOLID est un acronyme qui décrit cinq principes architecturaux qui doivent être respectés :
- S ingle Responsibility Principle (Principe de responsabilité unique) - Chaque module, classe, méthode ne doit servir qu’à une seule chose.
- O pen/Closed Principle (Principe ouvert/fermé) - Les modules doivent être ouverts pour être étendus et fermés pour être modifiés.
- L iskov Substitution Principle (Principe de substitution de Liskov) - Les types doivent pouvoir être remplacés par leurs sous-types.
- I nterface Segregation Principle (Principe de ségrégation des interfaces) - Aucun client ne devrait être forcé de dépendre de méthodes qu’il n’utilise pas.
- D ependency Inversion Principle (Principe d’inversion des dépendances) - Le modules de haut niveau ne doivent pas dépendre de modules de bas niveau. Les deux doivent dépendre d'abstractions. Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre d’abstractions.
S'efforcer de respecter ces cinq principes devrait aboutir à un système qui se distingue strictement des préoccupations.
Observation du principe de robustesse follow-the-robustness-principle
Le principe de robustesse stipule qu’il faut être tolérant dans ce que l’on accepte, et pointilleux dans ce que l’on envoie. En d’autres termes, lors de l’envoi de messages à un tiers, il convient de respecter scrupuleusement les spécifications. Cependant, lors de la réception de messages envoyés par un tiers, on doit accepter des messages non conformes, pour autant que leur signification soit claire.
Mise en œuvre de pics dans leurs propres modules implement-spikes-in-their-own-modules
Les pics et le code de test font partie intégrante de toute implémentation logicielle agile. Cependant, nous souhaitons nous assurer qu’ils ne se retrouvent pas dans la base de code d’exploitation sans le niveau de supervision approprié. Il est donc conseillé de créer des pics dans leurs propres modules.
Mise en œuvre de scripts de migration de données dans leur propre module implement-data-migration-scripts-in-their-own-module
En règle générale, les scripts de migration de données, bien qu’il s’agisse de code d’exploitation, ne sont exécutés qu’une seule fois au lancement initial d’un site. Par conséquent, dès que le site est en ligne, cela devient du code mort. Pour être sûr de ne pas créer du code d’implémentation qui dépend des scripts de migration, ceux-ci doivent être mis en œuvre dans leur propre module. Cela permet, en outre, de supprimer et de mettre hors service ce code juste après le lancement, et d’éliminer ainsi le code mort du système.
Respect des conventions Maven publiées dans les fichiers POM follow-published-maven-conventions-in-pom-files
Apache a publié des conventions de style, disponibles à l’adresse suivante : https://maven.apache.org/developers/conventions/code.html. Il est conseillé de suivre ces conventions, dans la mesure où elles permettent une mise en route rapide de nouvelles ressources.