Clean Architecture : Application des Principes SOLID à l’Architecture

Combien de temps dure la formation ?

0,50 jour(s)

Dans quelle(s) langue(s) la formation est-elle donnée ?

EN FR

Quand a lieu la prochaine session ?

Qui organise cette formation ?

OXiane est spécialisé dans la conception et la réalisation de formations informatiques et de supports de cours pédagogiques sur les dernières technologies. Nos différentes filières permettent de couvrir tous les besoins en formation que ce soit en IT au sens large, mais également "Utilisateurs" et "Soft Skills" en Management, Communication & leadership.

À qui s’adresse la formation ?

Architectes
Développeurs
Tech lead

Quels sont les objectifs poursuivis ou les compétences visées ?

Comprendre le rôle d'un architecte dans une équipe de développement logiciel
Comprendre la notion de composant en Clean Architecture, et sur quels critères des éléments logiciels sont-ils regroupés dans des composants communs, ou au contraire séparés dans des composants différents
Comprendre la différence entre réutilisabilité et maintenabilité
Comprendre le couplage entre composants
Comprendre pourquoi un graphe de dépendances doit être acyclique, et savoir comment briser les cycles dans un graphe cyclique

Quel est le contenu de la formation ?

Ce séminaire d'une durée d'une demi-journée se découpe en deux parties d'environ 80 minutes.
Partie 1 : Appliquer les principes SOLID aux modules d'une application
Cette première partie explique comment les principes SOLID peuvent s'appliquer à une architecture et comment les utiliser pour modulariser une application.
Les points développés sont les suivants :

Rappels des principes SOLID
Intérêts de l'application des principes SOLID en développement logiciel
Définition d'un composant en Clean Architecture, application du Principe S
Définition de la séparation de composants, application du principe I
Diagramme de tension

Partie 2 : Maintenir la dette technique sous contrôle
Cette seconde partie s'intéresse à l'organisation des modules : de quels modules un module doit-il dépendre ? Comment transmettre des informations d'un module à l'autre en respectant le graphe de dépendances.
Les points développés sont les suivants :

Danger de l'apparition de cycles dans un graphe de dépendance, comment briser les cycles, application du principe D
Défaut de l'approche en couches fonctionnelles
Inertie et volatilité d'un module, dépendance d'un module aux modules extérieurs
Mesure du caractère abstrait d'un composant
Relation entre caractère abstrait et inertie
Application à une application multi-tiers