Initiation à l'architecture logicielle - Partie 2

Publié
Commentaires Aucun

Avant de commencer cette partie, juste un petit rappel sur la conception objet (à accrocher au dessus de votre siège des toilettes):

Ouvert pout l’extension, fermé pour la modification.

Bien, commencons.

1 – Conception des couches

Dans les paragraphes suivants, nous allons concevoir étape par étape nos différentes couches.

1.1 – Appel vers une couche

Comme nous l’avons vus, la communication entre chaque couche doit être unidirectionnelle.

On peut tout à fait imaginer de changer le contenu ou les fonctions d’une couche du jour au lendemain. Or, il faut que cette modification quelle qu’elle soit n’ait pas ou très peu d’influence sur la couche supérieure.

De même, on peut imaginer éxécuter un morceau de code dès qu’une fonction de la couche est appellée.

Ces deux possibilitées impliquent qu’il est toujours préférable d’avoir un point d’entrée unique dans une couche. Ce point d’entrée doit être indépendant du contenu de la couche.

On utilise donc généralement un design pattern facade. Ceci est résumé par le schéma ci dessous:

Cas sans facade:

sans_facade

Si on modifie la couche Business, on casse les deux couches business et provider, la couche provider appelant directement les méthodes métier de la couche business. cf. schéma ci dessous:

avec_facade

C’est mauvais. Ca fait beaucoup de code à modifier dans chaque couche.

En utilisant une facade, on peut facilement cacher les détails de la couche business.

avec_facade

Lorsque l’on casse la couche business, seule l’implémentation de la facade est à revoir.

business

Vous pouvez maintenant modifier comme vous voulez votre couche business, vous n’aurez JAMAIS à modifier votre couche provider.
Qui plus est, si vous voulez ajouter une fonctionnalité lors de l’appel à n’importe quelle fonction de la couche (contrôles de sécurité, loggings, …), il suffit juste de l’y ajouter en proxifiant votre facade:

avec_facade_business

1.2 – Sortie d’une couche

On peut appliquer le même raîsonnement que précédement lorsque l’on souhaite sortir d’une couche en appellant les méthodes de la couche du dessous.
On peut tout à fait vouloir changer du jour au lendemain l’ensemble de la couche du dessous. Il est dans ce cas utile d’utiliser un proxy.

sortie_couche_ko

Appliquons maintenant les mêmes règles à la couche consumer:

sortie_couche_ok

1.3 – Appels vers les ressources externes

La couche consummer sera amenée à accéder à des ressources externes: Base de données, systèmes de fichiers, web services, …
Or, il se peut que certaines de ces ressources ne soient pas disponibles à l’éxécution, ou que l’on souhaite simplement changer le type de ressource. Aujourd’hui, mon programme va lire des fichiers, demain on va récupérer ces données en allant taper sur des web services. Comment concevoir mon programme pour que l’impact de ce changement y soit minimum ?

Avec des proxy ! Le pattern design proxy nous offre trois avanatges:
1 – Il permet de mettre en cache les services. Leur réutilisation sera donc plus rapide.
2 – Tous les accès à une ressource se font par le même proxy. Il suffit donc de gérér dans le proxy le cas où la ressource n’est pas disponible pour le gérer dans tout notre programme.
3 – Si on casse un type de ressoure, on casse seulement l’implémentation du proxy correspondant.

Ci dessous un diagramme de la couche consumer avec proxy:

couche_proxy

Si demain on veut aller taper sur un web service au lieu du système de fichier classique pour récupérer nos données, l’impact est très limité:

couche_proxy_impacts

À présent vous avez le gros de l’architecture de votre programme. Dans le prochain article, nous allons zoomer sur la couche business pour y décrire les approches par script de transaction et par domain model.

Auteur
Catégories architecture

Commentaires

Commentaires fermés pour cet article.

← Plus anciens Plus récents →