Cas pratiques Hexagonal Architecture

Contexte Une application doit interagir avec une base de données et une API externe. Le Problème L’équipe ne sait pas où placer ces implémentations techniques. Contraintes Expliquer le rôle des adaptateurs secondaires dans l’architecture hexagonale et leur relation avec les ports sortants. Livrable attendu Une explication structurée du positionnement des adaptateurs secondaires.

Contexte Un adaptateur importe directement des classes internes non exposées via port. Le Problème La frontière entre domaine et infrastructure est violée. Contraintes Identifier l’erreur architecturale et proposer une restructuration respectant les frontières hexagonales. Livrable attendu Une analyse claire du problème et une solution adaptée.

Contexte Un contrôleur HTTP contient validation et logique métier complexe. Le Problème La logique métier est couplée à la technologie web. Contraintes Identifier pourquoi cela viole l’architecture hexagonale et proposer une séparation correcte via un port entrant. Livrable attendu Une analyse structurée et une proposition de refactorisation conforme aux principes hexagonaux.

Contexte Un port dépend d’un adaptateur concret, créant une dépendance circulaire. Le Problème La règle d’inversion de dépendance est violée. Contraintes Analyser pourquoi cette situation est incorrecte et proposer une organisation respectant le principe des ports et adaptateurs. Livrable attendu Une analyse détaillée et une proposition de correction conforme à l’architecture hexagonale.

Contexte Le code suivant est présent dans le domaine : class OrderService { constructor() { this.db = new MySQLClient(); } save(order) { this.db.insert(order); } } Le Problème Le domaine dépend directement d’une implémentation technique. Contraintes Identifier la violation des principes hexagonaux et proposer une correction utilisant un port et un adaptateur. Livrable attendu Une analyse claire et une restructuration conceptuelle respectant l’architecture hexagonale.

Contexte Une équipe hésite entre architecture en couches classique et architecture hexagonale. Le Problème Les différences conceptuelles ne sont pas claires. Contraintes Comparer les deux approches en termes de dépendances, testabilité et isolation du domaine. Livrable attendu Une comparaison structurée mettant en évidence les avantages de l’architecture hexagonale.

Contexte Une équipe implémente des interfaces sans comprendre leur rôle précis. Le Problème Les ports sont mal catégorisés et mélangés. Contraintes Définir clairement la différence entre port entrant et port sortant dans l’architecture hexagonale et donner des exemples d’usage. Livrable attendu Une explication pédagogique permettant de distinguer les deux types de ports.

Contexte Une équipe rencontre des difficultés à tester la logique métier. Le Problème Les tests dépendent du framework web et de la base de données. Contraintes Expliquer comment l’isolation du domaine via ports et adaptateurs facilite les tests unitaires. Livrable attendu Une explication claire reliant architecture hexagonale et testabilité.

Contexte Une équipe souhaite adopter l’architecture hexagonale pour un nouveau projet. Le Problème Les développeurs confondent couches techniques et logique métier. Contraintes Expliquer les concepts fondamentaux de l’architecture hexagonale : noyau métier, ports et adaptateurs. Décrire le rôle de chaque élément et le principe d’inversion de dépendance. Livrable attendu Une explication structurée des composants principaux et de leur interaction.

Contexte Une application de gestion de tâches doit être développée. Le Problème Le projet ne dispose d’aucune organisation claire. Contraintes Proposer une structure de projet distinguant domaine, ports et adaptateurs. Expliquer la relation entre ces éléments. Livrable attendu Une proposition de structure claire illustrant l’application de l’architecture hexagonale.

Contexte Deux adaptateurs techniques dépendent l’un de l’autre via des classes utilitaires partagées. Le Problème Cette dépendance crée un couplage fort et complique les tests. Contraintes Identifier les risques et proposer une restructuration respectant les frontières hexagonales. Livrable attendu Une analyse détaillée du problème et une proposition de refactorisation cohérente.

Contexte Une plateforme e-commerce doit intégrer plusieurs fournisseurs de paiement. Le Problème L’implémentation actuelle dépend directement d’un fournisseur spécifique, rendant le changement complexe. Contraintes Proposer une architecture hexagonale avec un port sortant PaymentProvider et plusieurs adaptateurs concrets. Définir également un port entrant pour déclencher le cas d’usage de paiement. Livrable attendu Une architecture détaillée décrivant le noyau métier, les ports définis et les adaptateurs nécessaires, avec explication des dépendances.

Contexte Un microservice doit être développé pour gérer les notifications. Le Problème Les dépendances techniques risquent de complexifier son évolution. Contraintes Proposer une architecture hexagonale complète avec ports entrants pour les API et ports sortants pour les canaux de notification. Livrable attendu Une description détaillée du microservice structuré selon les principes hexagonaux.

Contexte Une application doit être accessible via API REST et interface CLI. Le Problème La logique métier est dupliquée dans chaque canal. Contraintes Proposer une architecture hexagonale utilisant un port entrant commun et plusieurs adaptateurs d’entrée. Livrable attendu Une architecture détaillée montrant la mutualisation du noyau métier via ports entrants.

Contexte Un adaptateur de base de données retourne des objets spécifiques à l’ORM directement au domaine. Le Problème Le domaine devient dépendant de détails techniques. Contraintes Identifier la violation architecturale et proposer une transformation des données au niveau de l’adaptateur. Livrable attendu Une analyse claire et une proposition respectant la séparation entre domaine et infrastructure.

Contexte Le code suivant est présent dans la couche métier : class CreateUserUseCase { execute(request, response) { const user = new User(request.body); response.status(201).json(user); } } Le Problème Le cas d’usage dépend directement des objets HTTP du framework. Contraintes Identifier les violations de l’architecture hexagonale et proposer une refactorisation utilisant un port entrant indépendant du framework. Livrable attendu Une analyse détaillée du problème et une proposition architecturale conforme aux principes hexagonaux.

Contexte Un cas d’usage doit effectuer plusieurs opérations atomiques sur un repository. Le Problème La gestion de transaction est codée dans l’adaptateur et non maîtrisée par le cas d’usage. Contraintes Proposer une organisation permettant au domaine de contrôler la transaction via un port abstrait. Livrable attendu Une architecture détaillée montrant la séparation des responsabilités transactionnelles.

Contexte Une application hexagonale doit être testée sans accès à la base de données réelle. Le Problème Les tests actuels utilisent l’implémentation concrète du repository. Contraintes Proposer une stratégie utilisant des adaptateurs simulés pour tester le noyau métier via les ports sortants. Livrable attendu Une stratégie détaillée expliquant comment isoler le domaine et injecter des implémentations fictives.

Contexte Une application existante suit une architecture en couches classique. Le Problème Les dépendances techniques contaminent progressivement la couche métier. Contraintes Proposer une stratégie progressive pour introduire ports et adaptateurs sans réécriture complète. Livrable attendu Un plan détaillé de refactorisation vers une architecture hexagonale respectant l’isolation du domaine.

Contexte Une application doit publier et consommer des événements métier. Le Problème La logique d’événement est actuellement codée dans l’infrastructure. Contraintes Proposer une architecture hexagonale intégrant des ports pour la publication et la consommation d’événements, tout en gardant le domaine isolé. Livrable attendu Une architecture détaillée montrant l’intégration des événements via ports et adaptateurs.

Contexte Des microservices prétendent suivre l’architecture hexagonale mais partagent directement des implémentations concrètes. Le Problème Le couplage inter-services viole les frontières des ports. Contraintes Identifier les violations et proposer une restructuration respectant isolation des domaines et contrats explicites. Livrable attendu Une analyse approfondie et une proposition d’architecture microservices conforme aux principes hexagonaux.

Contexte Un module utilitaire partagé importe indirectement des classes d’infrastructure utilisées dans le domaine. Le Problème Cette dépendance transversale viole la frontière hexagonale sans être immédiatement visible. Contraintes Identifier les risques architecturaux et proposer une restructuration éliminant la dépendance cachée. Livrable attendu Une analyse détaillée et une proposition garantissant respect strict des frontières ports/adaptateurs.

Contexte Une entreprise adopte Domain-Driven Design pour structurer ses sous-domaines. Le Problème Les frontières des contextes délimités ne sont pas clairement reflétées dans le code. Contraintes Proposer une architecture hexagonale alignée avec les bounded contexts, incluant ports explicites pour interactions inter-contextes. Livrable attendu Une architecture détaillée montrant cohérence entre DDD stratégique et implémentation hexagonale.

Contexte Une plateforme métier complexe est composée de plusieurs sous-domaines interconnectés. Le Problème Les frontières entre domaines sont floues et les dépendances techniques traversent les modules. Contraintes Proposer une architecture hexagonale par sous-domaine avec ports explicites, adaptateurs dédiés et isolation stricte du noyau métier. Décrire les frontières, les contrats d’interface et le sens des dépendances. Livrable attendu Une architecture détaillée montrant la structuration modulaire, les ports définis et la gestion des interactions inter-domaines.

Contexte Un cas d’usage implique plusieurs appels vers différents systèmes externes. Le Problème En cas d’échec partiel, l’état global devient incohérent. Contraintes Proposer une stratégie d’orchestration compatible avec l’architecture hexagonale, incluant ports sortants multiples et mécanismes de compensation. Livrable attendu Une architecture détaillée décrivant la gestion cohérente des transactions distribuées tout en respectant l’isolation du domaine.

Contexte Une application hexagonale doit intégrer logging, métriques et traçabilité avancée. Le Problème Les mécanismes d’observabilité sont injectés directement dans le noyau métier. Contraintes Proposer une stratégie permettant instrumentation via ports et adaptateurs dédiés, tout en conservant l’indépendance du domaine. Livrable attendu Une architecture détaillée intégrant observabilité et respect des principes hexagonaux.

Contexte Le domaine contient le code suivant : class InvoiceService { constructor(private ormEntityManager) {} generate(invoice) { this.ormEntityManager.persist(invoice); } } Le Problème Le noyau métier dépend directement d’un composant ORM. Contraintes Identifier les violations des principes hexagonaux et proposer une restructuration avec port sortant et adaptateur dédié. Livrable attendu Une analyse architecturale approfondie et une proposition conforme aux principes d’isolation du domaine.

Contexte Une application doit être exposée via REST, gRPC et CLI tout en consommant plusieurs sources de données. Le Problème Les implémentations sont dupliquées et fortement couplées. Contraintes Proposer une architecture hexagonale permettant mutualisation du noyau métier avec ports entrants multiples et adaptateurs secondaires spécialisés. Livrable attendu Une architecture complète décrivant la gestion des interfaces multiples et la centralisation de la logique métier.

Contexte Plusieurs équipes développent des modules hexagonaux selon des interprétations différentes. Le Problème Les conventions de ports et adaptateurs deviennent incohérentes. Contraintes Proposer une stratégie de gouvernance incluant conventions de nommage, règles de dépendance automatisées et revues architecturales. Livrable attendu Une proposition complète garantissant cohérence architecturale à l’échelle organisationnelle.

Contexte Une application legacy fortement couplée doit évoluer vers une architecture hexagonale. Le Problème Les dépendances techniques sont imbriquées dans la logique métier. Contraintes Proposer une stratégie de migration progressive introduisant ports et adaptateurs sans interruption de production. Livrable attendu Un plan détaillé de transformation architecturale respectant les principes hexagonaux.