Architecture N-tiers

Introduction

Une application peut commencer avec l'implémentation d'un IHM (Interface Homme-Machine), de fonctionnalités métier et un accès aux données :

• L'IHM affiche les données et interagit avec les utilisateurs.
• Les fonctionnalités métier exécute les traitements proposés par l'application.
• L'accès aux données permet d'obtenir et gérer les données.

Lorsque les besoins d’hébergement, de sécurité ou de montée en charge évoluent, il peut devenir utile de répartir ces responsabilités entre plusieurs composants déployés séparément.

L’architecture N-tiers répond à cette problématique en organisant l’application en tiers distincts, qui communiquent à travers d'interfaces explicites. En contrepartie, ces communications introduisent des contraintes réseau et d’exploitation qu’il faut prendre en compte dès la conception.

Présentation

Définition d'un tiers

Un tier est une unité d’exécution ou de déploiement distincte. Une architecture à trois tiers peut, par exemple, correspondre à :

1. Un tier de présentation : une application Web ASP.NET Core qui reçoit les requêtes et présente les résultats.
2. Un tier métier : une API ASP.NET Core qui exécute les cas d’utilisation et applique les règles métier.
3. Un tier de données : une base SQL Server qui conserve les informations.

Le navigateur appelle l’application Web, celle-ci communique avec l’API métier, puis l’API accède à la base de données. Le nombre de tiers peut varier : le « N » indique qu’il ne se limite pas à trois. De nouveaux tiers peuvent être ajoutés en fonction des besoins.

Ne pas confondre tiers et couches

Une couche sépare des responsabilités dans le code ; un tier sépare des composants dans leur déploiement. Une application peut ainsi contenir des projets Web, Application, Domain et Infrastructure tout en étant déployée comme une seule application : elle possède plusieurs couches, mais pas nécessairement plusieurs tiers applicatifs.

À l’inverse, déployer une application Web et une API métier dans des processus distincts crée une frontière entre deux tiers. Cette distinction est essentielle : ajouter un nouveau projet .NET ne crée pas à lui seul un nouveau tier.

Exemple simple en C#

Imaginons une application de gestion de commandes :

L’application Web est sollicitée par le client Web et lui retourne un flux permettant d'afficher les données et interagir avec les utilisateurs, en affichant une liste de commandes. Par exemple, L’API métier vérifie, qu’une commande peut être validée et calcule son montant. EF Core est utilisé par cette API pour accéder aux données contenues dans la base de données.

Cette répartition n’impose pas une technologie par tier. Elle impose surtout de définir les responsabilités par tier, les données échangées sur le réseau et quel composant a le droit d’accéder aux données. Les appels entre tiers peuvent aussi passer par une une solution de messagerie, lorsqu’une réponse immédiate n’est pas nécessaire.

Les avantages

Des responsabilités séparées

Chaque tier peut se concentrer sur ses propres responsabilités.

Des accès mieux contrôlés

Le tier de données peut être isolé et n’accepter que les connexions des composants autorisés.

Une capacité adaptée à chaque tier

Les ressources machines peuvent être adapter à chaque en fonction de leurs besoins respectifs.

Une évolution progressive

La configuration de l'hébergement de chaque tiers peut évoluer indépendamment des autres tiers.

Les limites

Une latence supplémentaire

Chaque échange entre tiers traverse le réseau et peut allonger le temps de réponse.

Une exploitation plus complexe

Plusieurs composants doivent être déployés, configurés, sécurisés et surveillés.

Des défaillances partielles

Un tier peut rester disponible alors qu’un autre répond lentement ou devient inaccessible.

Des dépendances entre déploiements

Un changement de contrat peut nécessiter une coordination entre les tiers qui communiquent entre eux.

Des tiers parfois artificiels

Un tier qui transmet simplement les requêtes ajoute de la complexité sans apporter de plus-value.

Bonnes pratiques avec .NET

Définir le rôle de chaque tier

Attribuer clairement la présentation, les règles métier et l’accès aux données aux composants concernés.

Maîtriser les échanges

Mesurer le coût des appels entre tiers.

Stabiliser les contrats

Documenter les API et contrôler leurs évolutions (ex : versionning).

Prévoir les défaillances réseau

Configurer délais limites, annulations et reprises.

Protéger le tier de données

Limiter les accès à la base en configuration composants autorisés.

Observer les parcours complets

Corréler journaux, métriques et traces pour suivre une requête à travers les différents tiers.

Quand cette architecture est-elle pertinente ?

L’architecture N-tiers est particulièrement adaptée lorsqu’une application possède déjà des composants séparés, que ses contraintes de sécurité demandent d’isoler la base de données. Elle peut aussi convenir à un environnement hybride, dans lequel certains composants sont déployés sur site et d’autres sont hébergés dans le cloud (Azure).

Pour les applications qualifiées de "simple", il est nécessaire d'évaluer si les besoins justifient réellement plusieurs tiers applicatifs. Une application ASP.NET Core structurée en couches peut déjà offrir une séparation explicite du code, avec moins de communications réseau à gérer.