On lit ou on entend par-ci par-là que pour suivre une architecture hexagonale, il faut appliquer tels principes de développement, que cela peut s’appliquer à tous les projets ou au contraire seulement à un nombre restreint, que le projet doit être organisé ainsi ou pas, etc. Cela finit en mantra sans aucune réflexion et sans explication. Dans cet article, il n’y aura ni injonction ni recette. Je pense qu’une fois les raisons et les fondamentaux connus, vous serez à même de suivre l’architecture hexagonale (ou non) de la manière la plus adaptée à votre projet et votre écosystème de développement.

Dans un précédent article, je parlais de l’utilisation d’un timeout sur les appels externes. Reprenons le dernier schéma : Le composant A abandonne l’appel vers B au bout de 80ms. Il doit maintenant répondre à son client. La meilleure réponse devrait être la vérité, c’est à dire retourner que le système rencontre un ralentissement. Au client de gérer cette erreur. Dans certains cas, il est acceptable (voire préférable) de retourner un résultat qui peut être :