Conception

Architecture client-serveur

client —requête—> serveur

• ex : client lourd — serveur de base de données

= applications monolithiques (obsolète)

Architecture N-Tiers

• ex : architecture 3-tiers avec des clients légers, un serveur d’application middle tiers, un serveur de base de données

= applications monolithiques (obsolète)

SOA (Service-Oriented Architecture)

Architecture orientée services

= un modèle de conception qui rend des composants logiciels réutilisables, grâce à des interfaces de services qui utilisent un langage commun pour communiquer via un réseau.

Des applications écrites dans des langages différents peuvent appelés les mêmes interfaces de services (web-services), qui comprennent tous les requêtes HTTP.

Notions de service (un seul objectif, mutualisation), d’interopérabilité (composants agnostiques, couplage faible), d’implémentations (bus de services, web services)

• ex : différents types de client communiquent avec différents services qui eux passent par un “bus” pour communiquer avec différentes infrastructures (bases de données et applications)

La SOA est à l’échelle de l’entreprise.

Les micro-services se développent de plus en plus car ils offrent plus de tolérance et de flexibilité : stratégie de mise en œuvre au sein des équipes de développement des applications. Ils peuvent communiquer entre eux sans état, à l'aide d'API indépendantes de tout langage.

Principes SOLID

• Single Responsability Principle ou principe de responsabilité unique

  “Un bout de code fait une et une seule chose.”

• Open / Closed Principle ou principe d’ouverture/fermeture

  “Une entité logicielle doit être ouverte aux extensions, fermée aux modifications.”

  On ne touche pas à ce qui fonctionne : on corrige les erreurs, on peut améliorer l’entité (héritage, surcharge, design patterns de structure) mais on crée de nouvelles entités pour ajouter des fonctionnalités.

• Liskov Substitution Principle ou principe de substitution de Liskov

  “Une sous-classe doit pouvoir se substituer à sa super-classe.”

  Une méthode doit être applicable à toutes les sous-classes.

• Interface Segregation Principle ou principe de ségrégation des interfaces

  “Une interface ne comporte que des méthodes en rapport avec elle-même et utiles aux classes qui l’implémentent.”

  Une interface est un contrat qui permet d’obliger un objet à utiliser certaines fonctionnalités.

• Dependency Inversion Principle ou principe d’inversion des dépendances

  “Les composants de haut niveau ne dépendent pas des modules de bas niveau mais d’abstractions.”

  Les classes abstraites et interfaces permettent d’avoir des couplages faibles entre les composants.

Patrons de conception (Design Pattern)

Solutions classiques à des problèmes récurrents de la conception de logiciels. Chaque patron est une sorte de plan ou de schéma personnalisables.

Patterns et anti-patterns :

Si les patterns sont basés sur les bonnes pratiques de la POO, les anti-patterns sont des erreurs courantes de conception de logiciels (“fausses bonnes idées”).

• ex : copier-coller, code spaghetti, blob,…

(Obsolète)

On s’est rendu compte que, pour passer d’un diagramme à du code, le niveau de détail dans les modèles était tel qu’ils en devenaient illisibles : contraire à l’objectif d’avoir des modèles faciles à comprendre.