Implémentation projet en Architecture hexagonal

Bonjour,

J'ai besoin de votre aide, car cela fait 11 ans que je developpe sur du spring 3 model MVC java 8, je suis en train de faire des entretiens pour trouver une nouvelle entreprise et lors de ces entretiens pratiquement à chaque fois on me demande si je connais l'architecture Hexagonale.

J'ai essayé de me renseigner sur internet pour en apprendre plus sur ça mais j'ai un peu de mal à comprendre.

Est-ce que l'achitecture héxagonale concerne uniquement la façon de coder ou elle concerne aussi l'architecture d'un projet (au niveau des serveurs) ?

Ce que je comprend c'est que dans ce modèle on met le code métier au coeur de l'application, mais quelles sont concrètement les différences avec le modèle mvc ?

Par exemple, dans le modele mvc, on interagit avec la BDD via des DAO, quelle est l'équivalent des DAO dans une architecture hexagonale ?

Merci d'avance pour votre aide

On sort le métier, qui ne dépend de fait pas d'un framework technique (Spring/Hibernate...).

On communique après avec le Design Pattern Adapter.

https://www.baeldung.com/hexagonal-a...ure-ddd-spring

https://www.youtube.com/watch?v=p029gSnlnfU

Merci pour le lien, j'ai regardé toute la video et je comprend un peu mieux.
Quand on me parlais d'architecture hexagonal je pensais que ca avait un lien avec les serveurs mais apparemment c'est pas du tout le cas, ca répond à une de mes questions.

Du coup si j'ai bien compris l'architecture hexagonal n'est pas un design pattern mais elle utilise des design pattern spécifique c'est bien ca?

Un peu.

Disons que l'architecture hexagonale n'est pas un pattern, mais plus une philosophie.

La technique change, les frameworks changent, mais pas le métier.

On peut changer aussi de serveur, de façon de déployer, voir de BDD (coucou Oracle et tes licences), mais le métier restera le même (normalement).

Du coup, on repart sur les fondamentaux: on fait une application pour répondre à un besoin client, pour répondre à une problématique métier.

De fait, on va, sans se soucier dans un premier temps de comment on va exécuter le code, le déployer..., répondre à un métier.

En fait, l'hexagone "métier", c'est vraiment un jar indépendant qui peut être sorti et utilisé dans différents projets.

Cet aspect doit être pris comme une possibilité.

Si le métier est complexe, avec des calculs bourrins, compliqués..., alors faire une architecture hexagonale apporte un vrai plus.

Mais si le métier est con comme la lune, là, l'architecture hexagonale peut-être une surcouche.

L'architecture hexagonale a aussi un avantage intéressant, on se centre sur le métier. L'application fait quoi? Ce qui permet d'écrire les tests avant, vu que l'on répond à la question de "l'application fait quoi", et de se poser la question de l'implémentation après.
De fait faire du TDD.

Attention néanmoins, les tests, c'est plus complexe qu'il n'y paraît. On a plusieurs familles de tests, comme le test unitaire, qui est mis en avant avec l'architecture Hexagonale, mais on a aussi le test Front-end pour les services REST, et le test d'intégration pour la DAO/gestion de la BDD.

Enfin, pour en revenir à l'hexagone, il ne parle que son propre langage (le métier) et il ne veut pas entendre parler technique (JPA/Hibernate/Spring).
Mais il donne l'occasion à ce qui est technique de se brancher sur lui-même, via le Design Pattern Adapter, qui du coup revient à la mode:
https://fr.wikipedia.org/wiki/Adapta...de_conception)
https://www.baeldung.com/java-adapter-pattern

Enfin, le métier (ou hexagone) ne veut pas voir de librairie extérieur, mais il peut y avoir de rare exception.

Par exemple, dans mon projet, je calcule des probabilités ( https://bitbucket.org/philippegibaul...r40k/src/main/ ), or, 1/3, c'est 1/3, pas 33%. De fait, pour gérer les fractions, j'utilise Apache Common Math ( https://commons.apache.org/proper/commons-math/ ).

Enfin, j'ai suivi la formation suivante qui permet de voir la clean architecture dans un contexte pratique:
https://wealcomecompany.com/wealcome...ture-formation

merci beaucoup PhilippeGibault, effectivement j'étais complètement perdu avec les différentes notions qui entre en jeu et tu les as très bien expliqué. C'est beaucoup plus clair pour moi maintenant, merci également pour les exemples de projet que tu m'a partagé.