Vue d'ensemble de l'architecture

Présentation d'une architecture multi-dépôts organisée en couches pour séparer les responsabilités, faciliter l'évolution et monter en charge avec un meilleur contrôle.

Objectif de cette architecture

L’architecture proposée cherche à résoudre un problème courant dans les systèmes qui grandissent :

• trop de responsabilités mélangées
• difficulté à déployer sans risque
• des intégrations externes qui contaminent le domaine
• une complexité croissante côté frontend et backend
• un couplage entre les équipes et les composants

Pour y répondre, le système est organisé en couches et en services aux frontières plus claires.

L’idée n’est pas d’ajouter de la complexité pour le plaisir, mais de répartir la complexité là où elle est plus facile à gérer.

Les 7 couches

1. Presentation

C’est ici que vit l’interface utilisateur. Elle affiche les écrans, gère l’état, valide les formulaires côté client et consomme les APIs.

2. API Gateway

C’est le point d’entrée principal. Elle applique l’authentification, le routage, la limitation de débit, la journalisation et d’autres capacités transversales.

3. BFF

Il agrège et transforme les données destinées à l’UI. Il réduit la complexité du frontend et évite que le client connaisse trop de détails internes.

4. Microservices

Ils contiennent la logique métier organisée par domaines ou bounded contexts. C’est ici que vivent les règles, les cas d’usage, les événements de domaine et la persistance.

5. Event Bus

Il permet une communication asynchrone entre les services au moyen d’événements. Il favorise le découplage temporel et la construction de processus distribués.

6. ACL

Elle protège le domaine face aux systèmes externes ou legacy. Elle traduit les modèles et encapsule les adaptateurs afin de ne pas contaminer le core métier.

7. Data / External Systems

Cela inclut les bases de données, le cache, les systèmes hérités et les fournisseurs tiers.

Pourquoi séparer en couches ?

Séparer en couches permet :

Clarté des responsabilités

Chaque partie du système a un objectif plus spécifique.

Moindre couplage

Le frontend n’a pas besoin de connaître les détails internes de chaque microservice. Les services de domaine ne devraient pas dépendre directement du modèle d’un ERP hérité.

Scalabilité technique

Vous pouvez faire monter en charge des composants différents selon leurs besoins réels.

Scalabilité organisationnelle

Les équipes peuvent travailler sur des périmètres plus clairs, avec un ownership défini.

Évolution maîtrisée

Modifier une pièce affecte moins les autres si les frontières sont bien définies.

Communication entre les couches

Dans cette architecture cohabitent deux grandes formes de communication :

Communication synchrone

On l’utilise lorsqu’une couche a besoin d’une réponse immédiate. Par exemple :

• frontend → gateway
• gateway → BFF
• BFF → microservices

Cela se fait généralement via HTTP ou GraphQL/REST.

Communication asynchrone

On l’utilise lorsqu’un service publie un fait et que d’autres réagissent sans avoir besoin de répondre de façon immédiate.

Par exemple :

• ms-orders publie OrderPlaced
• inventory réagit
• notifications réagit
• analytics réagit

Les deux cohabitent parce qu’elles répondent à des besoins différents.

Multi-dépôts : pourquoi séparer les dépôts

L’architecture est pensée en plusieurs dépôts, un par couche ou par service principal.

Cela permet :

• l’indépendance de déploiement
• un ownership plus clair
• une taille moindre par dépôt
• une meilleure isolation par domaine

Mais cela exige aussi :

• des standards partagés
• des accords de versionnage
• de la discipline sur les contrats
• le contrôle du shared kernel

Le multi-dépôts n’est pas automatiquement meilleur ; c’est une décision qui doit accompagner un besoin réel de séparation.

Principes qui soutiennent l’architecture

Séparation des responsabilités

Chaque couche résout un problème différent.

Domaine protégé

Les règles métier doivent vivre au bon endroit et ne pas se contaminer avec des modèles externes.

Contrats explicites

La communication entre les parties du système doit être définie et compréhensible.

Évolution indépendante

Chaque partie doit pouvoir changer avec le moins de friction possible.

Observabilité et sécurité dès la conception

Elles ne doivent pas être ajoutées à la fin comme un correctif.

Ce que cette architecture ne signifie pas

Il est important d’éviter certaines mauvaises interprétations.

Cela ne signifie pas que tout doive être un microservice

Il faut séparer lorsqu’il existe une frontière claire et un besoin réel.

Cela ne signifie pas que plus de couches soit toujours mieux

Chaque couche doit justifier la valeur qu’elle apporte.

Cela ne signifie pas que la complexité disparaisse

La complexité ne disparaît pas ; elle est mieux organisée.

Cela ne signifie pas que le shared kernel puisse croître sans contrôle

Partager trop peut recréer de forts couplages.

Comment parcourir cette section

Nous vous recommandons de progresser ainsi :

1. Frontend
2. API Gateway
3. BFF
4. Microservices
5. Event Bus
6. ACL
7. Data / External Systems
8. Shared Kernel et contrats
9. Dépôts

Résumé

Cette architecture organise le système en couches aux responsabilités différenciées pour favoriser la clarté, la scalabilité et une évolution maîtrisée. Elle ne cherche pas à imposer de la complexité, mais à placer chaque type de complexité là où il peut être le mieux géré.