Architecture Patterns

Sommaire :

• Découpage des applications
• Monolithe
• N-tier
• Orchestrateur
• Architecture orientée service
• Microservices
• Application sans serveur
• Per to peer
• Structure des applications
• Couches
• Micro-noyau / Plugin
• Command Query Responsibility Segregation (CQRS)
• Event Sourcing
• Interfaces utilisateur
• Model - View - Controller (MVC)
• Model - View - Presenter (MVP)
• Model - View - View Model (MVVM)
• Divers
• Transactions ACID
• Data - Context - Interaction (DCI)
• Entity - Component - System (ECS)

Découpage des applications

Monolithe

Un seul executable.

• - Avantages :
  • - Facile à comprendre, implémenter, tester, déployer.
• - Inconvénients :
  • - Risque de couplage fort et de code complexe.
  • - Même technologie pour toutes les parties.

N-tier

Plusieurs tiers, séparés par des frontières techniques.
Notamment : 3 tiers : présentation (client) - logique (serveur) - base de données.

• - Avantages :
  • - Implémentations indépendantes.
  • - Extensibilité.
• - Inconvénients :
  • - On doit souvent modifier tous les tiers.

Orchestrateur

L'orchestrateur coordonne les interactions et les flux de données entre les différents services.

• - Avantages :
  • - Implémentation simple.
• - Inconvénients :
  • - Mise à l'échelle limitiée par l'orchestrateur central.
  • - Couplage fort.

Architecture orientée service

Plusieurs services, chacun responsable d'une activité.
Les services communiquent entre eux via un Enterprise Service Bus (ESB).

• - Avantages :
  • - Faible couplage entre les services.
  • - Extensibilité.
• - Inconvénients :
  • - Interdépendances entre les équipes.
  • - Coût des développements.

Microservices

Architecture orientée service, mais décentralisée, sans ESB : les micro-services s'appellent directement les uns les autres.
Les microservices sont déployés indépendamment et automatiquement. Ils sont autonomes et observables.

• - Avantages :
  • - Agilité du déploiement.
  • - Fiabilité par la gestion des échecs.
• - Inconvénients :
  • - Schémas de communications compliqués.

Application sans serveur

Fonctions indépendantes, à courtes durées de vie, qui s'exécutent à la demande, dans des containeurs.
On s'appuie sur une plateforme function as a service.

• - Avantages :
  • - Grande extensibilité.
  • - Grande agilité.
  • - Faible coût au début.
• - Inconvénients :
  • - Dépendance vis-à-vis de la plateforme.
  • - Pas de persistence dans les fonctions.
  • - Délai d'instanciation des fonctions.

Per to peer

Des applications en réseau communiquent sans serveur central.
Les applications sont intermittentes et se découvrent dynamiquement (éventuellement avec un serveur central juste pour cela).
C'est utile pour partager des ressources.

• - Avantages :
  • - Faible coût au début.
  • - Grande extensibilité.
• - Inconvénients :
  • - Failles de sécurité.

Structure des applications

Couches

Chaque couche appelle la couche en-dessous (jamais le contraire).

• - Avantages :
  • - Organisation facile.
• - Inconvénients :
  • - Monolithe ensuite difficile à découper.
  • - Beaucoup de code pour passer d'une couche à une autre.

Micro-noyau / Plugin

Le noyau contient la logique de base, étendue par des plugins.

• - Avantages :
  • - Flexibilité.
• - Inconvénients :
  • - Difficle de définir une API suffisante pour les plugins à venir.
  • - Séparation difficile entre le noyau et les plugins.

Command Query Responsibility Segregation (CQRS)

Les opérations d'écriture et de lecture sont complètement séparées, en agissant sur deux bases de données synchronisées.

• - Avantages :
  • - Opérations de lecture plus simples et plus performantes.
  • - Mises à l'échelle indépendantes des opérations de lecture et d'écriture.
• - Inconvénients :
  • - Complexe.
  • - Délai de synchronisation (cohérence éventuelle).

Event Sourcing

On enregistre les évènements au lieu du dernier état.
Pour connaitre l'état, on rejoue les évènements (réhydratation). Pour optimiser, on peut partir d'instantanés (snapshots).

• - Avantages :
  • - Traçabilité des changements.
  • - En cas d'erreur logique, pas besoin de corriger la base de données.
• - Inconvénients :
  • - Complexe.
  • - Difficultés pour changer la structure des évènements.

Interfaces utilisateur

Model - View - Controller (MVC)

Permet de séparer la représentation interne des données de leur présentation à l'utilisateur.

• - Model : données (data-model).
• - View : représentations (graphiques), éventuellement multiples, des données.
• - Controller : réception des entrées utilisateur, logique des actions, et modification des données.

• - Avantages :
  • - Séparation des responsabilités.
• - Inconvénients :
  • - Partie controller très grosse.

Model - View - Presenter (MVP)

• - Model : données.
• - View : réception des entrées utilisateur, et représentation des données.
  • - Passive View : ne connait pas le Model, toute la logique est dans le Presenter.
  • - Supervising Controller : la View sait rendre les données du Model, et n'utilise le Presenter que pour les logiques complexes.
• - Presenter : logique des actions, et modification des données.

• - Avantages :
  • - Adapté aux clients lourds.
  • - Testabilité.
• - Inconvénients :
  • - Partie Presenter peut être trop grosse.

Model - View - View Model (MVVM)

• - Model : données et logique.
• - View Model : liaison bidirectionnelle des données.
• - View : interactions utilisateur et représentation des données.

Divers

Transactions ACID

Pour être fiable, une transaction doit répondre aux critères suivants :

• - Atomicité : la transaction se fait complètement ou pas du tout.
• - Cohérence : la transaction laisse le système dans un état valide.
• - Isolation : la transaction est indépendante des autres qui peuvent être exécutées simultanément.
• - Durabilité : le résultat de la transaction est permanent.

Data - Context - Interaction (DCI)

Ce motif permet de séparer le comportement du système du domaine de connaissances.

• - Data : modèle du domaine de connaissances (data-model).
• - Context : cas d'usage (use-case), qui assigne un objet à chacun de ses rôles, puis lance l'interaction.
• - Interaction : implémentation des rôles, qui interagissent sans connaitre les objets assignés au rôles.

Entity - Component - System (ECS)

Ce motif est utilisé pour les jeux vidéos. Les objets, entities, sont crées par composition de components, qui ne contiennent que des données :

• - Entity : un objet qui n'est composé que de son identifiant.
• - Component : données associées à une entity, via son identifiant ; plusieurs components, éventuellement de différents types, peuvent être associé à une entity.
• - Système : processus qui agit sur les components qui l'intéressent.

À étudier :

• - Wikipedia: Software design patterns.
• - Wikipedia: Software architecture.
• - Wikipedia: Programming paradigm.

La dernière mise à jour de cette page date de juillet 2023.

Le contenu de ce site est, en tant qu'œuvre originale de l'esprit, protégé par le droit d'auteur.
Pour tout commentaire, vous pouvez m'écrire à xavier.lamorlette@gmail.com.