Quand nous évoquons que l’architecture d’un SI repose sur Kafka ou Redis, sommes-nous vraiment en train de parler architecture ? Ne parlons-nous pas plutôt de design (ou d’implémentation) ? Cela nous est tous arrivés d’avoir la présentation d’une architecture qui ressemble à ceci : Ce qui est intéressant est la considération différente entre le service applicatif, NginX et Apache Kafka. Pourquoi, pour le service, n’avons-nous pas le framework et le langage utilisé ?

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 :

Quand on parle de système distribué, le terme « disponibilité » revient souvent. Et souvent, on associe la disponibilité à la scalabilité horizontale. Comme s’il suffisait de multiplier les instances d’un service pour avoir un système disponible. Avant de continuer, définissons ce qu’est la disponibilité. Un système est disponible s’il répond ET s’il répond dans les temps. Pouvons nous considérer un système comme disponible si son temps de réponse est supérieur à 5 secondes alors qu’il est normalement de 30 ms ?

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.

Cet article est pour… Les équipes de développement dont le travail repose sur des spécifications fonctionnelles. Le contexte Nous sommes dans une société avec des équipes métiers et une équipe de développement interne. Le chef de projet informe le démarrage d’un nouveau projet et communique un document, plutôt un pavé, qui contient les spécifications fonctionnelles. Pour être sûr de répondre aux besoins client, des comités de relecture sont organisés avec les parties métier et développement pour apporter des questions et autres remarques.

Découverte d’un nouveau type de planète Jusqu’à récemment nous connaissions 2 types de planètes: les planètes sphériques (plus ou moins) comme la Terre les planètes sous la forme d’un disque, souvent reposé sur 4 éléphants qui eux-mêmes reposent sur une tortue Les scientifiques ont découverts les “Flat Square Planet”, des planètes de forme carrée. Afin d’en savoir plus, la NASA et l’ESA ont décidé de developper un nouveau rover pour étudier une planète de ce type.

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.