Architecture N-Tier #

Une architecture classique consiste à séparer un système en plusieurs couches. Il existe plusieurs variantes, mais concentrons-nous sur la version classique à trois couches :

• la présentation correspond à l’affichage des données et l’interaction avec le système. Par exemple: une interface graphique (interface web/smartphone ou native), API http…
• la logique-métier correspond au comportement du système, sa logique. Elle représente les cas d’utilisation de l’application. C’est la raison d’exister du système, là où se trouve la valeur principale.
• l’accès aux données correspond aux données qui sont employées par le système. Elles peuvent être persistantes si l’accès se fait au moyen d’une base de données. Elles peuvent être accessibles par une API externe ou via le système de fichiers. Elle est dépendante de l’infrastructure.

Une illustration est donnée ci-dessous (cf: source )

Ces trois couches devraient pouvoir évoluer de manière indépendante et être localisées sur des machines différentes. La logique-métier ne devrait pas savoir que ses objets sont persistés à l’aide d’une base de données relationnelle ou qu’un des attributs sera présenté en rouge dans une interface graphique. Etant donné que la logique-métier est la raison d’exister du système, cette couche ne doit jamais dépendre des autres couches. Il devrait être possible de changer de base de données sans avoir à modifier la logique-métier par exemple. Tout l’intérêt d’une bonne abstraction est de garantir un couplage faible entre les couches et d’abstraire également les parties techniques.

Une variante que j’apprécie personnellement est l’architecture hexagonale (ou ports and adapters) qui présente la logique-métier au centre et qui dépendent uniquement d’abstractions (représentées par des interfaces). Celles-ci sont connectées à des implémentations situées dans les couches extérieures.