@Chlouchloutte m'a faite découvrir ce diagramme il y a quelques minutes.
J'avoue que je ne sais pas trop quoi en penser dans le sens où il m'apparaît comme très procédurale. Typiquement en OOP (Object Oriented Programming), nous avons une encapsulation des données et les traitements qui s'appliqueront sur elles au sein d'une même classe. Or, le découpage en couche implique une séparation des données dans des structures et l'application d'une logique applicative, répartie en couche. Les structures / entités traversant toutes les couches.
Ce n'est pas objet pour un sou. Et ce sera même quasiment impossible de coder proprement en objet avec de telles architectures puisque chaque couche insistera pour séparer les entités des traitements. De facto, nous nous retrouverons avec une armada de développeurs arguant que l'objet "sainul" puisqu'ils ne pourront tout simplement jamais exprimer facilement en objet. Ainsi, les classes issues de l'OOP se résumeront à être de simple modules (au sens Functional-Programming du terme, c'est-à-dire un namespace de fonctions) et les instances ne seront plus que des singletons, qu'ils soient gérés manuellement ou via Spring.
Pour faire de l'objet, il faut que votre architecture soit orientée objet (je simplifie). Pour coder en fonctionnel, il faut que vos données soit accessibles dans des monades (je simplifie aussi). Pour tirer le meilleur des deux mondes, il vous suffit d'avoir une architecture orientée objet, des algorithmes codés via une approche fonctionnelle. Mais visiblement, mes contemporains préfèrent une lutte de religion radicale que de découvrir les avantages de l'autre camp.
@Chlouchloutte j'aurai quand même besoin de te reposer des questions.