Parlez-moi de l'architecture hexagonale et de ses…

L'architecture hexagonale (Ports et Adapters) est un modèle architectural proposé par Alistair Cockburn. Son objectif est d'isoler le cœur de la logique métier de l'application des dépendances externes (UI, bases de données, services tiers).

Origine :

Alistair Cockburn a présenté le concept en 2005. L'idée principale est née en réaction aux architectures en couches traditionnelles, où la logique métier était souvent fortement couplée à la couche d'infrastructure. Cockburn cherchait à créer une architecture permettant de développer et tester la logique métier indépendamment de la façon dont elle interagit avec le monde extérieur. Le nom "hexagonal" symbolise la capacité de l'application à interagir avec différents types d'"adaptateurs" externes via des "ports". Un hexagone a été choisi comme figure abstraite ayant suffisamment de "faces" (ports) pour interagir avec différents systèmes.

Principes fondamentaux :

Noyau (Core / Domaine): Contient la logique métier pure et les objets de domaine. Il ne dépend pas des technologies externes.
Ports: Interfaces définissant l'interaction entre le noyau et le monde extérieur. Il existe deux types de ports:
- Entrants (Driving Ports): Définissent comment les agents externes (par exemple, interface utilisateur ou API) peuvent invoquer les fonctions du noyau.
- Sortants (Driven Ports): Définissent comment le noyau peut interagir avec des services externes (par exemple, base de données ou API tiers). Le noyau définit ces interfaces, mais ne les implémente pas.
Adaptateurs (Adapters): Implémentent les ports et servent de lien entre le noyau et les éléments externes. Il existe également deux types d'adaptateurs:
- Entrants (Driving Adapters): Transforment les requêtes des agents externes en un format compréhensible par le noyau (par exemple, un adaptateur UI).
- Sortants (Driven Adapters): Transforment les appels du noyau en un format compréhensible par les services externes (par exemple, un adaptateur de base de données).

Avantages :

Isolation: Le cœur de la logique métier n'est pas dépendant des technologies externes.
Testabilité: Le cœur peut être testé indépendamment, sans avoir besoin de lancer toute la pile.
Flexibilité: Il est facile de remplacer un adaptateur par un autre sans modifier le cœur (par exemple, passer d'une base de données à une autre).
Maintenabilité: Les différentes parties de l'application (noyau et adaptateurs) peuvent être développées et évoluer indépendamment.

Application en Frontend :

Bien que l'architecture hexagonale soit plus associée au backend, ses principes peuvent également être appliqués dans le frontend pour structurer l'application cliente:

Noyau: Modules contenant la logique métier et l'état de l'application (par exemple, reducers Redux, store Zustand, composants avec logique pure sans liaison au DOM).
Ports: Interfaces définissant comment l'UI interagit avec la logique (entrantes) et comment la logique interagit avec des API externes ou un stockage local (sortantes).
Adaptateurs: Composants UI qui gèrent l'entrée utilisateur et appellent les ports (adaptateurs entrantes), et services qui effectuent des requêtes HTTP ou travaillent avec l'API du navigateur comme localStorage (adaptateurs sortants).

Exemple de structure (abstraite):

📦 app
 ┣ 📂 core
 ┃ ┣ 📂 domain
 ┃ ┃ ┗ 📜 todos.ts  // Description de l'entité Todo
 ┃ ┣ 📂 application
 ┃ ┃ ┗ 📜 todoService.ts // Logique métier pour Todo
 ┃ ┗ 📂 ports
 ┃ ┃ ┣ 📜 in/ITodoUseCase.ts // Port entrant (interface pour UI)
 ┃ ┃ ┗ 📜 out/ITodoRepository.ts // Port sortant (interface pour accès aux données)
 ┣ 📂 infra
 ┃ ┣ 📂 adapters
 ┃ ┃ ┣ 📂 in/reactUIAdapter.tsx // Adaptateur entrant (composant React)
 ┃ ┃ ┗ 📂 out/apiTodoRepository.ts // Adaptateur sortant (implémentation d'accès API)

Parlez-moi de l'architecture hexagonale et de ses origines.