Available courses

Application distribuée

ARCHITECTURE HEXAGONALE

Ces documents présentent l'architecture hexagonale, un modèle de conception logicielle conçu par Alistair Cockburn pour isoler la logique métier des contraintes techniques. Ce système repose sur le concept de ports et d'adaptateurs, permettant à une application de rester agnostique vis-à-vis des interfaces utilisateurs ou des bases de données. L'objectif principal est de garantir que le cœur du domaine ne dépende d'aucun élément externe, facilitant ainsi les tests automatisés et la maintenance à long terme. En traitant les entrées et les sorties de manière symétrique, cette structure protège le code contre l'obsolescence technologique et la dispersion des règles métier. Enfin, les sources détaillent les stratégies de mise en œuvre et de migration pour transformer des systèmes classiques souvent trop rigides.

PRINCIPES SOLID

SOLID est un acronyme mnémotechnique désignant cinq principes de conception orientée objet destinés à rendre les logiciels plus compréhensibles, flexibles et maintenables. Cet acronyme a été créé par Michael Feathers et promu par Robert C. Martin,.
Voici une définition courte de chaque principe :
• S - Single Responsibility Principle (Principe de Responsabilité Unique) : Un module ne doit être responsable que vis-à-vis d'un seul et unique acteur (ou groupe d'utilisateurs),. Cela implique qu'une classe ne doit avoir qu'une seule raison de changer.
• O - Open/Closed Principle (Principe Ouvert/Fermé) : Une entité logicielle doit être ouverte à l'extension mais fermée à la modification,. Introduit par Bertrand Meyer, ce principe vise à permettre d'ajouter de nouveaux comportements sans modifier le code source existant,.
• L - Liskov Substitution Principle (Principe de Substitution de Liskov) : Les objets d'un type donné doivent pouvoir être remplacés par des objets d'un sous-type sans altérer la cohérence ou la correction du programme,.
• I - Interface Segregation Principle (Principe de Ségrégation des Interfaces) : Aucun code ne doit être forcé de dépendre de méthodes qu'il n'utilise pas. Il est préférable d'avoir plusieurs interfaces spécifiques plutôt qu'une interface générale volumineuse.
• D - Dependency Inversion Principle (Principe d'Inversion des Dépendances) : Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau ; les deux doivent dépendre d'abstractions,. De même, les abstractions ne doivent pas dépendre des détails, mais les détails doivent dépendre des abstractions.

DESIGN PATTERNS

Les design patterns sont des solutions éprouvées à des problèmes récurrents de conception logicielle. On distingue trois catégories principales :

•       Patterns créationnels : Factory, Singleton, Builder, Abstract Factory, Prototype

•       Patterns structurels : Adapter, Decorator, Facade, Proxy, Composite, Bridge

•       Patterns comportementaux : Strategy, Observer, Command, State, Template Method, Chain of Responsibility

Un lead tech doit savoir reconnaître ces patterns dans le code existant, les appliquer judicieusement, et surtout comprendre quand ne pas les utiliser pour éviter la sur-ingénierie.