Optez pour une architecture pertinente et pérenne
Cet article fait partie d’une série nommée “Maximisez les chances de réussir votre projet informatique”.
Celui-ci aborde le thème de l’architecture.
Le rôle de cet article n’est pas de détailler toutes les architectures, mais au moins donner d’en citer quelques unes à connaître, donner de premiers éléments et des liens pour en savoir plus.
Nous introduirons :
- Le CQRS
- L’Event Sourcing
- Le DDD
- Les Microservices
Le choix des patterns d’architecture à suivre ne se fait pas à la légère. Chacune a ses forces, mais surtout ses faiblesses, gardez ça en tête avant de partir sur l’une ou plusieurs.
CQRS
L’architecture CQRS (pour Command and Query Responsibility Segregation) est une architecture qui permet de séparer l’écriture (Command) de la lecture (Query).
L’adoption d’une telle architecture, dans des cas bien précis, augmente les performances et peut simplifier la prise en charge de cas complexes.
⚠️ Attention, l’architecture CQRS n’est pas la solution à tout. Elle est parfaitement adaptée aux objets qui subissent des séquences d’opérations, tels qu’on le trouve souvent en milieu bancaire
L’architecture CQRS est opposée aux modèles CRUDs (Create, Read, Update, Delete). Cette architecture peut néanmoins n’être utilisée que sur des parties spécifiques d’un système (un domaine, mentionné dans l’architecture DDD, par exemple). En effet, chaque domaine ou même microservice peut être modélisé de la façon la plus adaptée à ses besoins fonctionnels.
💡 Convaincu par l’utilité du CQRS ? Pour commencer, c’est tout simple : coupez vos interfaces en deux. D’un côté, la partie Read, de l’autre, la partie Write.
👉 Vous pourrez trouver plus d’informations sur l’architecture CQRS en lisant cet article, Pourquoi avoir choisi d’utiliser l’architecture CQRS ?
Event Sourcing
Ce pattern met en avant la gestion de la séquence de changements d’état, sous forme d’événements. Plutôt que de ne garder que le dernier état d’une donnée, on garde la succession d’évènements qui la font évoluer.
Cela nous permet entre autres de comprendre pourquoi une donnée est dans tel état beaucoup plus facilement, d’effectuer de la reprise de donnée, et d’annuler un événement intermédiaire puis reconstruire…
💡 Pour l’une de mes missions, nous devions réaliser un logiciel de calcul de paie. Avec du recul, suivre cette architecture aurait été beaucoup plus efficace : en l’absence d’Event Sourcing, les régulations représentent une difficulté technique impressionnante, alors qu’il aurait fallu repartir d’une base “correcte” et appliquer les événements un à uns pour aboutir sur le résultat souhaité
💡 Le pattern CQRS est souvent utilisé avec l’Event Sourcing
👉 Vous pourrez trouver plus d’informations sur l’Event Sourcing en lisant cet article, Pattern: Event sourcing
DDD, conception pilotée par le domaine
Un code écrit en utilisant les mêmes termes que le métier est plus simple à comprendre et à maintenir. Partant de ce principe, le DDD (Domain Driven Design) préconise que l’accent doit être mis sur le domaine et la logique associée, notamment en créant une collaboration entre les experts métier et les experts techniques pour affiner de manière itérative un modèle conceptuel.
⚠️ Attention, malgré de nombreux gains techniques, la mise en place d’une telle architecture peut être complexe et donc coûteuse. Son application devrait être appliquée dans les seuls cas où la séparation des domaines apportent une facilité de compréhension et un découplage facile.
L’AOP (Aspect-Oriented Programming) est un paradigme de développement qui peut aider à séparer l’aspect fonctionnel de l’aspect technique.
Il existe différentes implémentations qui correspondent à cette conception d’architecture.
Les architectures hexagonale, clean et en oignons ont toutes le même objectif : la séparation des préoccupations afin d’avoir des applications faiblement couplées et à haute cohésion.
👉 Les trois architectures mentionnées ci-dessous sont d’ailleurs si semblables qu’il est difficile de voir la différence entre chacune, si ce n’est la façon de l’expliquer. L’article Layers, Onions, Ports, Adapters: it’s all the same, de Mark Seemann en parle.
Architecture hexagonale
Avec l’architecture hexagonale, définie par Alistair Cockburn en 2005, ou également appelée “Ports & Adapters”, met le métier (le domaine) au cœur de l’application.
👉 Vous pouvez retrouver plus d’informations dans cet autre article, tout simplement nommé L’architecture hexagonale
A la différence des autres conceptions architecturales, celle-ci met moins l’accent sur le couches, ce qui a mon sens demande plus d’efforts intellectuels, d’attention et de pratique pour l’ensemble des développeurs.
Clean architecture
Introduite par Ivar Jacobson mais rendue connue par Robert C. Martin en 2008, elle a pour objectif de permettre d’être indépendant des frameworks, de l’UI, de la base de données, et d’être beaucoup plus facilement testable.
👉 Vous pouvez retrouver plus d’informations sur ce billet publié par Robert C Martin
Cette architecture place également le domaine au centre de l’application, communique via différentes couches d’abstractions et met l’accent sur l’utilisation des principes SOLID.
Architecture en oignons
L’architecture en oignons, introduite par Jeffrey Palermo en 2008, est très proche de l’architecture hexagonale, hormis le fait que l’accent sur différentes couches est davantage mis en valeur, et que chaque couche ne dépend que des couches encore plus à l’intérieur.
👉 Vous pouvez retrouver plus d’informations sur le site de Jeffrey Palermo
Les quatre principes de cette architecture sont les suivants :
- L’application est construite autour d’un modèle objet indépendant
- Les couches internes définissent les interfaces. Les couches externes les implémentent
- La direction du couplage est vers le centre
- Tout le code de l’application peut être compilé et exécuté séparément de l’infrastructure
Ce qu’il faut retenir
Ces trois conceptions d’architecture mettent toutes le métier au centre de l’application. Elles placent les frameworks et l’infrastructure aux frontières, maximisant la cohésion et minimisant le couplage.
👉 En lien, je vous mets un très bon article, bien détaillé, autour de ces modèles de conception. DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together
Comme toute architecture, celles-ci comportent leurs défauts :
- Tous les langages ne sont pas adaptés
- Beaucoup de code pour répondre à une feature
- Courbe d’apprentissage longue et complexe
Elles sont en opposition avec l’architecture la plus courante, un modèle en trois couches, celle de la présentation, celle du métier, et celle de la persistance.
Microservices
Cette architecture, à la mode, remplace le bon gros vieux monolithe, plus difficile à maintenir.
Voici quelques avantages :
- La mise en place de microservices peut aider à responsabiliser les équipes si une équipe est en charge d’en réaliser en quasi-intégralité. Il est bien sûr intéressant que plusieurs équipes puissent travailler sur le même, auquel cas je recommande tout de même que l’équipe “responsable du microservice”, contribue avec l’équipe qui réalise, et valide la Merge Request (nous parlerons un peu plus loin de la loi de Conway).
- Ils permettent de travailler sur des domaines plus restreints, la maintenance est simplifiée à partir du moment où les domaines sont bien définis. Ils s’adaptent tout à fait dans un contexte DDD.
- Si une fonctionnalité n’est plus d’actualité, il est alors plus facile de la retirer sans remettre en question le reste de l’application. Un microservice buggué/mal conçu pourrait être refait à partir d’une feuille blanche plus facilement.
- Les microservices sont plus facilement scalables. On déploie plusieurs instances qui correspondent à la fonctionnalité surchargée.
- Un microservice peut utiliser les technologies les plus adaptées au besoin fonctionnel qu’ils représentent.
- Chaque microservice peut être déployé et testé de manière indépendante.
Les inconvénients existent, ne les sous-estimez pas !
- Attention au terme micro. Les “nano-services” en est un anti-pattern.
- L’architecture est plus complexe, les tests faisant intervenir toutes les briques sont plus importants.
- Le cloisonnement des données peut être problématique, des données sont souvent redondées (même si ça ne devrait pas être en problème en soi, avec de bons moyens de synchronisation)
- Toutes les organisations doivent se mettre à jour sur leurs pratiques : l’exploitant, l’opérateur, les développeurs, …
⚠️ La mise en place d’une telle architecture peut être coûteuse. Les dangers ne peuvent être ignorés : les performances sont souvent dégradées par davantage d’échanges en passant par des couches de sérialisation et désérialisation. Le déploiement doit être outillé.
Heureusement, de nos jours, il existe de nombreux moyens qui aident au déploiement et à la supervision de tels systèmes. Si un microservice tombe, il peut être relancé automatiquement
Et le côté pérenne, dans tout ça ?
Le côté pérenne vient du fait que le code produit en respectant ces architectures est beaucoup plus maintenable et réutilisable.
En mettant le domaine au centre de l’application et les frameworks aux bords, il devient plus facile de remplacer un framework par un autre sans mettre en péril l’intégralité de l’application.
Les microservices sont spécialisés, n’embarquent que le strict nécessaire, et peuvent être changés plus facilement, rendant l’intégralité du système pérenne.
Pour plus d’informations
Consultez le reste de la série “Maximisez les chances de réussir votre projet informatique” :
