Architecture N-Tiers... N-Layers ?

Le n-tiers c'est de la bal, aujourd'hui et depuis plus d'une décennie tout les softwares se targuent d'être conçus en couche, d'être modulaire, fini l'application monolytique qu'ils disaient. 

Chaque couche a une responsabilité bien définie pour apporter aux développements modularités, simplicité, couplage lâche entre couche... Bref la panacée de la conception software... bref c'est dans wikipedea https://en.wikipedia.org/wiki/Multitier_architecture , pas besoin de faire Polytechnique. La version française se concentre à juste titre sur le 3-Tiers.

Mais que vois-je ? Un souci de traduction entre les 2 définitions anglais/français, une petite subtilité c'est glissée dans la définition anglaise une distinction est faite entre Layers (couches logiques) et Tiers (couches physique)... alors que pour les français 3-Tiers c'est 3 couches logiques. Une erreur dans Wikipedia vous me direz ? Et bien non les définitions sont justes, c'est bien l'usage... alors attention à la lecture de documentations en anglais. Mais alors le 3-Tiers à la Française ne correspond pas du tout au 3-tiers à l'anglaise...

Quand à moi je parle bien de couche logique, de toute façon avec le web les couches logiques et les couches physiques ne correspondent plus, en effet dans un application web la couche de présentation est à la fois exécutée coté serveur (JSP, ASPX...) mais aussi coté client en javascript, css...
On a déjà vu, des architectes s'emmelé là dedans, tiens il me maque une couche (oui il est de bon alois d'en avoir au moins 3) y a qu'a dire que la base de données Oracle en est une ? Non ? Cela fera bien dans mon powerpoint... non mais c'est quoi ce délire.

Voila un graphe anglophone standard et on parle bien de Layers...

 

Bref le N-Tiers francophone est une petite incompréhension de l'anglais réadapté et digérée... amusant non ?

Les couches c'est bon mangez en mais gare à l'indigestion !

Dans le monde réel, souvent ça pique un peu, entre les différents furieux et ayatollah de la couche, du découplage, ce n'est pas rare de voir un nombre de couches gargantuesques... 6..7... peut-être plus... sans parler du mécanisme de découplage mis en oeuvre, les portes de l'enfer s'ouvrent en grand. Déjà qu'au delà de 4 ça sent le souffre... oui on parlait du 3-tiers... enfin 3 layers.. je sais plus des couches qu'on disait. 

La mise en œuvre c'est quelque chose, et c'est souvent du grand n'importe quoi. Et le pire c'est qu'avec un bataillon de développeurs ça va marcher... OK quelques problèmes de performances mais on peut toujours se reposer sur la loi de Moore en décalant la date de livraison suffisamment, on les aura les perfs et ça partira en production. Et puis à l'âge du Cloud du cluster la puissance est infinie ! Au pire on attend l'ordinateur quantique et ça roule ! 

Sans compter la maintenance... ou ajouter un champ dans l'interface devient un véritable parcourt du combattant, chaque couche doit être traverser comme une tranchée ennemie sous le feu de la mitraille, spectacle qui laisse perplexe la plupart des clients...

"Vous voulez un champ date... ok je mets en place une équipe commando, ils travaillerons jour et nuit et dans 10 jours vous l'avez !.... Quoi il faut l'initialiser à la date du jour ! J'appelle Chuck Norris lui seul peu ajouter une règle dans la bonne couche, mais comptez 15 jours".  

Le pire c'est que ça a fini par marcher, validant de facto une telle conception et c'est parti pour le projet suivant. Oui le copier-coller étant le design pattern le plus utiliser, reproduire l'erreur est la base.

Ah que je suis médisant... quelle image je donne des architectes... non il ne faut pas généraliser loin de là. C'est qu'on entend souvent parler des projets qui ont des difficultés, voir en échec, et ceux réalisés dans l'état de l'art passe inaperçu. Il y a alors une valorisation de l'équipe qui après un échec sortira le projet dans la douleur, ils seront souvent montrés en exemple et on fera appel à eux pour les projets importants... qui seront à leur tour douloureux. Mais je m'égare.