Architecture Hexagonale : construire une application Web & Mobile moderne, maintenable et orientée métier

L’architecture hexagonale s’impose aujourd’hui comme l’un des piliers du développement logiciel moderne. Pensée pour placer la logique métier au cœur des applications, elle permet de concevoir des systèmes robustes, évolutifs et réellement testables, tout en restant indépendants des frameworks, des interfaces et des technologies.

Dans cet article, nous allons :

  • Comprendre ce qu’est réellement l’architecture hexagonale
  • Explorer ses principes fondamentaux
  • Voir comment elle s’articule naturellement avec le Domain-Driven Design
  • Découvrir une mise en pratique concrète dans un projet Web & Mobile partagé
  • Comprendre comment développer sans UI, guidé uniquement par les tests
  • Poser les bases d’une architecture multi-plateforme durable

Bienvenue dans une autre manière de concevoir le logiciel.

1. Qu’est-ce que l’architecture hexagonale ?

L’architecture hexagonale (aussi appelée Ports & Adapters) propose une vision radicalement différente de la conception logicielle.
Plutôt que de structurer une application autour de ses frameworks, de sa base de données ou de son interface utilisateur, elle place la logique métier au centre.

Le cœur de l’hexagone

Au centre se trouve le noyau métier :

  • les règles métier
  • les entités
  • les cas d’usage
  • les invariants du domaine

Ce cœur ne dépend de rien d’autre que de lui-même. Il est pur, stable et testable.

Les couches périphériques

Autour de ce noyau gravitent des couches périphériques :

  • interface utilisateur (Web, Mobile, API…)
  • persistance (base de données, stockage local…)
  • services externes (API, outils tiers…)

Ces couches n’ont jamais le droit d’imposer leurs contraintes au cœur métier.

Ports et adaptateurs

La communication entre le cœur et l’extérieur se fait via :

  • des ports (interfaces définies dans le domaine)
  • des adaptateurs (implémentations techniques)

Le cœur ne connaît que des abstractions.
Les détails techniques sont interchangeables.

L’inversion des dépendances

Principe clé :
👉 les dépendances pointent toujours vers le cœur, jamais l’inverse.

Cela permet :

  • de changer de base de données sans toucher au métier
  • de remplacer une UI sans impacter la logique
  • de tester le métier sans infrastructure

2. Pourquoi adopter l’architecture hexagonale ?

L’architecture hexagonale apporte des bénéfices concrets :

  • ✅ Logique métier indépendante des frameworks
  • ✅ Testabilité maximale
  • ✅ Évolutivité et refactor serein
  • ✅ Adaptation facile à de nouveaux canaux (Web, Mobile, API…)
  • ✅ Meilleure lisibilité du code
  • ✅ Réduction de la dette technique

Elle transforme la manière de penser un projet :
on ne code plus une interface, on modélise un métier.

3. Architecture hexagonale et Domain-Driven Design (DDD)

L’architecture hexagonale et le Domain-Driven Design sont profondément complémentaires.

Une vision commune

Les deux approches partagent un objectif central :

comprendre, modéliser et protéger le cœur métier.

  • Les entités du DDD trouvent naturellement leur place dans le cœur de l’hexagone
  • Les agrégats structurent les règles métier
  • Les bounded contexts se traduisent par des modules isolés avec leurs propres ports et adaptateurs

Exemple concret

Dans une application de gestion financière :

  • Le domaine Wallet gère les portefeuilles et leurs règles
  • Le domaine Transaction gère les flux d’argent
  • Le domaine Category structure les dépenses

Chaque domaine possède :

  • ses entités
  • ses règles
  • ses ports
  • ses adaptateurs

Le tout reste parfaitement découplé.

4. Un projet concret : construire une app Web & Mobile partagée

Pour illustrer ces principes, imaginons Broney, un outil de gestion de budget multi-plateforme.

Objectifs du projet

  • Partager la logique métier entre Web et Mobile
  • Développer sans dépendre d’une UI
  • Mettre en place une architecture maintenable
  • Travailler en TDD
  • Être capable d’évoluer sans douleur

Stack technique (agnostique par principe)

  • Monorepo : Nx
  • Web : Remix
  • Mobile : Expo
  • Langage : TypeScript
  • Tests : Vitest
  • State management : Zustand
  • Validation : Zod
  • Backend : Supabase
  • CI/CD : GitHub Actions

👉 Le point clé : le cœur métier n’a aucune dépendance à ces outils.

5. Structurer le projet : le monorepo

La structure cible du projet est la suivante :

apps/
├─ web
└─ mobile

libs/
├─ ui
├─ tailwind
└─ core

La librairie core est le cœur du système.

6. La lib core : l’architecture hexagonale en pratique

Structure interne

libs/core/src
├─ wallet
│   ├─ domain
│   │   ├─ wallet.ts
│   │   ├─ wallet.repository.ts
│   │   └─ wallet.service.ts
│   ├─ infrastructure
│   │   ├─ in-memory-wallet.repository.ts
│   │   ├─ local-storage-wallet.repository.ts
│   │   └─ supabase-wallet.repository.ts
│   ├─ user-interface
│   │   └─ wallet.store.ts
│   └─ tests
│       ├─ wallet.test.ts
│       └─ wallet.service.test.ts

7. Développer sans UI grâce au TDD

L’un des grands avantages de l’architecture hexagonale est de pouvoir développer toute la logique métier sans interface graphique.

La démarche

  1. Écrire un test
  2. Implémenter la logique minimale
  3. Faire passer le test
  4. Refactor
  5. Recommencer

Les tests deviennent le premier client de votre application.

Exemple : le domaine Wallet

Cas d’usage :

  • créer un portefeuille
  • récupérer tous les portefeuilles
  • mettre à jour
  • supprimer

Ces règles sont définies avant toute UI, uniquement via des tests.

8. Domain, Infrastructure et User Interface

Domain

  • Entités
  • Règles métier
  • Interfaces (ports)
  • Services métier

👉 aucune dépendance technique

Infrastructure

  • Implémentations concrètes des ports
  • Base de données
  • APIs
  • Stockage local

👉 dépend uniquement du domaine

User Interface

  • Points d’entrée
  • Stores Zustand
  • Controllers
  • Hooks

👉 consomme le cœur métier sans le modifier

9. Partager la logique entre Web et Mobile

Grâce à cette architecture :

  • le Web et le Mobile utilisent exactement la même logique métier
  • seuls les adaptateurs changent
  • le store Zustand est réutilisable partout

Résultat :

  • moins de bugs
  • moins de duplication
  • plus de cohérence

10. Bonnes pratiques et conseils

  • 🔍 Prioriser la clarté du code
  • 🧪 Tester en profondeur le domaine
  • 📚 Documenter les choix architecturaux
  • 🧩 Limiter les dépendances
  • 🔄 Itérer en continu

Conclusion

L’architecture hexagonale n’est pas qu’un pattern.
C’est un changement de mentalité.

Elle permet de :

  • remettre le métier au centre
  • construire des applications durables
  • réduire la dette technique
  • partager la logique sur plusieurs plateformes
  • évoluer sans tout casser

En adoptant cette approche, vous ne développez plus seulement une application :
vous construisez un système solide, testable et orienté valeur.

L’architecture hexagonale est aujourd’hui l’un des socles les plus fiables pour bâtir l’avenir du développement Web et Mobile.

Abonnez-vous au blog de Yield Studio

Restez en contact avec Yield Studio et recevez les nouveaux articles de blog dans votre boîte de réception.

Oops! Something went wrong while submitting the form.
Yield Studio traitera vos données conformément à sa politique de confidentialité

Yield Studio recrute les top 1% des meilleurs profils tech, product, design

Yield Studio développe des produits digitaux en un temps record

Simulateur

Bienvenue dans le
simulateur d’estimation

Sélectionnez
vos besoins

Sélectionnez un ou plusieurs choix

Définissez les
fonctionnalités

Sélectionnez un ou plusieurs choix

Dernière
étape !

Renseignez votre adresse mail pour recevoir l’estimation !
Obtenez l’estimation
Précédent
Suivant

Bravo ! Vous avez terminé
l’estimation de votre future app !

Vous recevrez dans votre boite mail l’estimation personnalisé. Une estimation vous offre la possibilité de vous projeter dans un budget, vous permettant ainsi de planifier en toute confiance. Néanmoins, chez Yield, nous adoptons une approche agile, prêts à remettre en question et ajuster nos évaluations en fonction de l'évolution de vos besoins et des spécificités de votre projet.
Retour au site
Oops! Something went wrong while submitting the form.