Implémenter une architecture — du domaine au code
Une fois les objectifs clarifiés et le domaine métier découpé, comment passer à l'implémentation technique sans créer de dette ni de désordre ?
Poursuivons avec notre exemple de prise de commande e-commerce (Catalogue, Panier, Paiement, Commande) pour aborder les choix de structuration du code, de qualité, de performance et d'exploitation.
Les questions clés pour implémenter l'architecture
❓ Comment éviter un code désordonné et difficile à maintenir ?
Pour éviter que le code technique vienne polluer les règles métier, on applique une architecture hexagonale (ports & adaptateurs). Le cœur de l'application définit des contrats (des interfaces), et ce sont les outils techniques externes qui viennent s'y brancher. Cela permet de changer une base de données ou un outil sans réécrire la logique métier.
🛒 Dans notre exemple : le calcul du montant du panier ne connaît ni PostgreSQL ni l'API bancaire. Il demande simplement à une interface de sauvegarder les données et à une autre de valider le paiement. On peut ainsi tester tout le processus sur sa machine sans vraie base de données.
❓ Comment concevoir des API durables ?
Une bonne API doit rester stable pour que les applications clientes (web, mobile) ne cassent pas à chaque mise à jour. On définit des formats d'échange clairs, on ajoute un numéro de version dans l'URL, et on documente chaque route pour que toute l'équipe comprenne son fonctionnement.
🛒 Dans notre exemple : les points d'entrée POST /v1/panier/items et POST /v1/panier/payer sont fixés dès le départ. Même si le backend change sa manière interne de traiter le paiement en v2, l'application mobile en v1 continue de fonctionner sans interruption.
❓ Comment garantir la qualité du code au quotidien ?
On met en place plusieurs niveaux de vérification automatique. Les tests unitaires vérifient les petits calculs en une fraction de seconde, les tests d'intégration testent les liaisons avec la base de données, et les linters s'assurent que le code respecte un style propre et lisible.
🛒 Dans notre exemple : un test unitaire vérifie en quelques millisecondes que l'ajout d'une quantité négative dans le panier est refusé. Un test d'intégration vérifie ensuite qu'un paiement réussi enregistre bien la commande en base et décrémente le stock disponible.
❓ Comment observer et diagnostiquer l'application en production ?
On ne peut pas corriger ce qu'on ne voit pas. Chaque action de l'utilisateur doit générer des logs clairs et structurés. On attribue un identifiant unique à chaque requête dès son arrivée, ce qui permet de suivre son trajet complet à travers tous les composants.
🛒 Dans notre exemple : quand un client clique sur "Payer", on génère un identifiant unique correlationId. Si le paiement échoue, on recherche cet identifiant pour voir exactement où le blocage a eu lieu (refus bancaire, timeout réseau ou rupture de stock de dernière minute).
❓ Comment optimiser les performances sans complexifier inutilement ?
La règle d'or est de mesurer avant d'optimiser. On identifie les données très souvent consultées mais peu modifiées pour les garder en mémoire rapide (cache), tout en conservant un accès direct à la base pour les opérations critiques en temps réel.
🛒 Dans notre exemple : la liste des fiches produits du catalogue est stockée en cache rapide pour afficher les pages instantanément à des milliers de visiteurs. En revanche, le stock restant au moment du clic "Payer" est lu directement en base pour éviter les réservations en double.
❓ Comment déployer de nouvelles versions sereinement ?
On automatise la chaîne de livraison avec un pipeline CI/CD. Dès qu'un développeur propose une modification, les tests sont exécutés automatiquement. Si tout est vert, la mise en production se fait sans couper le service, avec la possibilité de revenir en arrière instantanément en cas de problème.
🛒 Dans notre exemple : quand on met à jour le module de commande, la nouvelle version est d'abord déployée pour 5 % des utilisateurs. Si le taux de commandes réussies reste normal, le déploiement s'étend à 100 %. En cas d'erreur anormale, le système revient immédiatement à l'ancienne version.
❓ Comment garder une trace des choix techniques importants ?
Les équipes changent et la mémoire s'efface. Pour chaque décision d'architecture majeure, on rédige une courte fiche décisionnelle (ADR) expliquant le problème, les options évaluées et la raison du choix final. Ce document est stocké directement dans le dépôt de code.
🛒 Dans notre exemple : on écrit un document court expliquant pourquoi on a choisi de passer par une file de messages asynchrone pour la génération de la facture au lieu de bloquer l'utilisateur sur la page de paiement pendant que le PDF est généré.
Exemple concret : architecture d'une application e-commerce
Prenons l'exemple d'une application de commande en ligne, conçue selon une architecture hexagonale (ports & adapters) :
Le domaine (centre) ne dépend d'aucun détail technique : les adapters entrants (API, worker) et sortants (BDD, paiement, messages) s'y connectent via des ports/interfaces.
Pourquoi ça fonctionne :
- Le domaine reste testable en isolation (pas de dépendance à la BDD ou au framework HTTP).
- On peut remplacer un adapter (ex. changer de prestataire de paiement) sans toucher au domaine.
- Les tests d'intégration ciblent les adapters, les tests unitaires ciblent le domaine.
Voir aussi :
- Architecture applicative — conception et bonnes pratiques pour la modélisation métier et le découpage DDD.
- Architecture SI pour l'infrastructure, la scalabilité et l'exploitation à l'échelle.