DEVELOPPEUR D'APPLICATION
Architecture logicielle
L’architecture d’un logiciel décrit la manière dont seront agencés les différents éléments d’une application et comment ils interagissent entre eux. Cette étape est donc l’une des premières étapes du développement logiciel et intervient lors de la phase de conception.
Caractéristique d'une bonne architecture logicielle
Une bonne architecture, se définit par:
La première des qualités d'une bonne application est de permettre de tester l'application de façon automatique (tester dans un environnement qui n'est pas celui de l'environnement de production avec des données proche de celle de la production).
Évolution
L'architecture doit prendre en compte les évolutions futures du logiciel en fonction du besoin métier. Si on ne peut anticiper les évolutions elles-mêmes, elle doit dans ce cas être assez souple pour permettre une possible évolution. Une bonne architecture est indépendante des choix techniques si un choix technique est impossible voir trop coûteux, c'est dire que l'architecture n'est pas évolutive .
Simplicité
Une architecture complexe est souvent source de défaillance et peut créer de la dette technique, impacter les performances ou l'évolutivité d'une application. Elle est due à une mauvaise conception, une sur-ingénierie initiale ou à l'inverse un manque de conception global qui induit une complexification progressive du logiciel dans le temps.
De plus, le logiciel doit avoir une architecture «compréhensible» pour faciliter sa prise en main. Pour cela, il est nécessaire de: respecter les standard sa fin qu'il soit possible pour une personne ne connaissant pas le projet d'intervenir.
Maintenabilité
Une bonne architecture intègre aussi l'outillage nécessaire à sa maintenance. Cela permet notamment de récupérer de l'information de manière centralisée lorsqu'il y a une erreur afin de pouvoir la traiter efficacement et d'agir en conséquence.
Architecture Hexagonal
L’architecture hexagonale, ou architecture à base de ports et d’adaptateurs, est un patron d’architecture utilisé dans le domaine de la conception des logiciels. Elle vise à créer des systèmes à base de composants d’application qui sont faiblement couplés et qui peuvent être facilement connectés à leur environnement logiciel au moyen de ports et d’adaptateurs. Ces composants sont modulaires et interchangeables ce qui renforce la cohérence des traitements et facilite l’automatisation des tests.
Principes de l'architecture Hexagonale
- Séparer explicitement User-Side, Business Logic et Server-Side
- Les dépendances vont vers la Business Logic
- On isole les frontières par des Ports et Adapters
L’architecture hexagonale, c’est inspiré de l’approche de conception
, qui est une approche de conception de logiciel qui se focalise sur un domaine métier complexe.
User-Side
Cʼest le côté par lequel lʼutilisateur ou les programmes extérieurs vontinter agir avec lʼapplication. On y trouve le code qui permet ces interactions. Typiquement, votre code dʼinterface utilisateur, vos routes HTTP pour une API, vos sérialisations en JSON à destination de programmes qui consomment votre application sont ici.
Business Logic
Cʼest la partie que lʼon veut isoler de ce qui est à gauche et à droite. On y trouve tout le code qui concerne et implémente la logique métier. Le vocabulaire métier et la logique purement métier, ce qui se rapporte au problème concret que résout votre application, tout ce qui en fait la richesse et la spécificitée staucentre.Dans lʼidéal, un expert du métier qui ne sait pas coder pourrait lire un bout de code de cette partie et vous pointer une incohérence(true story, ce sont des choses qui pourraient vous arriver!).
Server-Side
CES ici qu’on var trouver ce dont votre application a besoin, ce quelle pilote pour fonctionner. On y trouve les détails d’infrastructure essentiels comme le code qui interagit avec votre base de données, les appels au système de fichier, ou le code qui gère des appels HTTP à d’autres applications dont vous dépendez par exemple.
Principe Architectural
En plus de rendre le métier indépendant des systèmes extérieurs, les interface permettent de satisfaire le fameux D de SOLID, ou Dependency Inversion Principle. Ce principe dit:
Les modules de haut niveau ne doivent pas dépendre des 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 de s'abstractions.
Si on nʼavait pas lʼinterface, on aurait un module de haut niveau(la Business Logic) qui dépendrait dʼun module de bas niveau(le Server-Side).
Qu’est ce qu’un port?
Un port est un point d’entrée et de sortie indépendant du consommateur vers/depuis l’application. Dans de nombreuses language, ce sera representé par une interface. Par exemple, il peut s’agir d’une interface utilisée pour effectuer des recherches dans un moteur de recherche. Dans notre application, nous utiliserons cette interface comme point d’entrée et/ou de sortie sans aucune connaissance de l’implémentation concrète qui sera réellement injectée là où l’interface est définie.
Qu’est ce qu’un adapteur?
Un adaptateur est une classe qui transforme(adapte) une interface en une autre.
Inversion de contrôle
Une caractéristique à noter sur ce pattern est que les adaptateurs dépendent d’un outils pécifique et d’un port spécifique(en implémentant une interface).Mais notre logique métier ne dépend que du port(interface),qui est conçu pour répondre aux besoins de la logique métier, elle ne dépend donc pas d’un adaptateur ou d’un outil spécifique.
Pour découpler les classes, nous utilisons l’injection de dépendances, en injectant des dépendances dans une classe au lieu de les instancier à l’intérieur de la classe, et l’inversion de dépendances, en faisant dépendre la classe d’abstractions (interfaces et /ou classes abstraites)au lieu de classes concrètes.Cela signifie que la classe dépendante n’a aucune connaissance de la classe concrète qu’elle vautiliser, elle n’a aucune référence au nom de classe complet des classes dont elle dépend.
Proposition d’implémentation de l’architecture
