Cinq livres, un système : de la décision d’architecture à une production fiable

ARCCLOUD / L’ATELIER DE L’ARCHITECTE / 02

Jeudi, tout fonctionnait. Vendredi, deux personnes ont obtenu le même créneau.

L’équipe a ajouté une intégration avec le stock, corrigé le formulaire et livré une version. Le pipeline était au vert. Le lendemain matin, un conseiller a accepté deux interventions pour la même équipe. Une pièce était déjà réservée pour la première ; la seconde avait déjà déclenché l’envoi d’une confirmation au client. Chaque morceau de code faisait quelque chose de raisonnable. C’est l’ensemble du processus qui ne tenait plus.

Dans ces moments-là, l’architecture cesse d’être un dessin fait de rectangles. Elle devient une réponse à des questions précises : qui peut confirmer un créneau, à qui appartient la réservation et qu’avons-nous promis à la personne de l’autre côté de l’écran ?

J’ai choisi cinq livres qui aident à aborder ces questions dans le bon ordre. Nous partirons des exigences, entrerons dans le code, remettrons de l’ordre dans un système existant et vérifierons enfin si nous savons le maintenir après sa mise en production. Chaque livre apporte un regard différent. Tous nous ramènent à la responsabilité des conséquences de nos décisions.

Exigences · Les modèles dans le code · Refactoring · Frontières et événements · Fiabilité · Mettez vos décisions à l’épreuve

01 / FUNDAMENTALS OF SOFTWARE ARCHITECTURE

Une bonne conception commence par un problème que l’on sait nommer.

Mark Richards et Neal Ford présentent les styles d’architecture et les caractéristiques de qualité d’un système. Leur point de départ est simple : toute décision d’architecture a un prix. En gagnant en indépendance de déploiement, nous pouvons rendre les erreurs plus difficiles à suivre. En simplifiant une transaction, nous pouvons lier plusieurs changements à un même déploiement. Ce livre se lit utilement comme un entraînement à justifier ses choix. Présentation de la deuxième édition par l’éditeur.

Chez Service Nord, trois personnes font évoluer une seule application. La plupart des incidents concernent les créneaux et les réservations de pièces. C’est une raison suffisante pour commencer par les règles du processus. Savoir que l’entreprise souhaite une « architecture moderne » ne nous dit pas encore quelle solution l’aidera.

C’est seulement maintenant que la discussion sur le style d’architecture prend son sens. Pour cette entreprise, nous choisissons d’abord un monolithe modulaire: un seul déploiement, avec des frontières de responsabilité explicites. Nous simplifions ainsi la mise en service et pouvons utiliser des transactions locales. Nous acceptons aussi le coût d’une livraison commune et la nécessité de surveiller les dépendances entre les modules.

Ce choix répond aux conditions décrites. Si une équipe distincte commence à faire évoluer la planification, ou si sa charge devient très différente de celle du reste de l’application, nous reviendrons sur cette décision. Un bon document d’architecture précise également le signal qui doit conduire à le relire.

02 / PATTERNS OF ENTERPRISE APPLICATION ARCHITECTURE

Un modèle n’aide que s’il correspond à la complexité des règles.

Martin Fowler, avec ses coauteurs, décrit les problèmes récurrents des applications de gestion : organisation de la logique, persistance des données ou modifications concurrentes d’une information. L’ancienneté de l’ouvrage n’enlève rien à la valeur de ses questions. En pratique, il est utile de distinguer un simple Transaction Script d’un Domain Model plus riche et de comprendre la frontière d’une Unit of Work. Le livre sur le site de l’auteur.

Supposons que l’administration modifie la description d’un poste de maintenance. Vérifier les droits, contrôler la longueur du texte, enregistrer : un cas simple peut rester un simple script transactionnel. Il n’est pas nécessaire de construire tout un modèle autour de lui.

Confirmer une réparation est plus délicat. Il faut un devis accepté, les pièces et une équipe. Si ces conditions sont vérifiées séparément dans le contrôleur, dans un traitement de nuit et dans une intégration, nous aurons au bout de quelques mois trois définitions différentes d’une « intervention confirmée ». Il devient utile de réunir la règle dans un seul modèle.

public enum WorkOrderState { Draft, Confirmed }

public sealed record ConfirmationEvidence(
    bool QuoteAccepted,
    bool PartsReserved,
    bool TechnicianReserved);

public sealed class WorkOrder
{
    public WorkOrderState State { get; private set; }

    public void Confirm(ConfirmationEvidence evidence)
    {
        if (State == WorkOrderState.Confirmed) return;
        if (!evidence.QuoteAccepted || !evidence.PartsReserved ||
            !evidence.TechnicianReserved)
            throw new InvalidOperationException("Confirmation is incomplete.");

        State = WorkOrderState.Confirmed;
    }
}

Ce fragment illustre une règle, pas un processus prêt pour la production. Dans une application réelle, la preuve de réservation doit provenir d’un contrat de confiance et se rapporter à la bonne intervention ainsi qu’à la bonne version. Il faut aussi gérer l’expiration des réservations, les autorisations et les écritures concurrentes. Trois booléens envoyés par le navigateur ne peuvent pas constituer cette preuve.

Le test unitaire confirme que le modèle refuse des conditions incomplètes. Le test d’intégration lance deux écritures simultanées et vérifie le mécanisme de concurrence en base. Ce sont deux assurances différentes. Le test de la classe seule ne révélera pas une double réservation effectuée par deux processus.

Unit of Work permet de regrouper les changements qui appartiennent à une même opération de persistance. Elle n’étend pas automatiquement la transaction à un stock externe, à un broker et à un serveur de messagerie. Mieux vaut dessiner cette frontière avant que le code ne la franchisse sans que personne ne s’en aperçoive. Présentations succinctes des modèles : Transaction Script, Domain Model et Unit of Work.

03 / DOMAIN-DRIVEN REFACTORING

Clarifiez d’abord les significations. Séparez ensuite le code.

Alessandro Colla et Alberto Acerbis montrent comment appliquer le DDD à un système qui existe déjà : du langage métier et des contextes jusqu’aux changements de structure et de base de données. La démarche compte autant que le résultat : améliorer progressivement les frontières tout en préservant un produit qui fonctionne. Un système modulaire peut être un bon résultat de refactoring ; extraire un microservice demande une justification propre. Le livre chez l’éditeur.

Dans notre entreprise, le mot « prêt » signifie trois choses différentes selon la personne qui l’emploie. Le conseiller pense au prix convenu, le magasinier à la pièce mise de côté et le technicien à la réparation effectuée. Une seule colonne Status n’efface pas cette différence. Elle la dissimule jusqu’au premier cas inhabituel.

Nous commençons à définir les frontières en parlant avec les personnes qui font le travail. Nous partons d’une réclamation précise : que s’est-il passé, qui a pris la décision et quel fait manquait alors ? C’est de ces échanges que sort un modèle utile. Les noms des dossiers doivent ensuite le refléter.

Comment faire évoluer un ancien système sans tout réécrire ?

1. Choisissez un scénario qui fait mal. Par exemple, la confirmation d’un créneau. Formulez la règle avec la personne responsable du processus.
2. Protégez par des tests le comportement dont vous avez besoin. Déterminez quels résultats actuels sont corrects. Figer une ancienne erreur dans un test n’en fait pas une exigence.
3. Introduisez un seul point d’accès. Le code des interventions demande une réservation à la planification par l’intermédiaire d’un contrat. Il ne modifie pas directement ses tables.
4. Transférez la responsabilité des écritures. Définissez le moment de la bascule et un responsable unique. Deux mécanismes indépendants qui écrivent les mêmes données rendent les divergences plus difficiles à détecter.
5. Comparez les résultats et supprimez l’ancien chemin. Vérifiez les données historiques, les cas limites et le plan de retour en arrière. Vous pourrez ensuite supprimer les dépendances devenues inutiles.

À ce stade, la base peut rester commune. Être responsable des données signifie maîtriser leurs modifications, leurs règles et leur contrat ; cela n’impose pas automatiquement un serveur de base de données distinct. Dans un monolithe modulaire, on peut commencer par les schémas, la visibilité des types et les tests de dépendances. Lorsque l’isolation doit être plus forte, on ajoute les autorisations et les frontières d’exécution adaptées.

04 / SOFTWARE ARCHITECTURE: THE HARD PARTS

Quand un module devient un service, le réseau entre dans la discussion.

Neal Ford, Mark Richards, Pramod Sadalage et Zhamak Dehghani analysent les décisions difficiles sur la taille des services, les données, les contrats et les processus distribués. Ce livre est particulièrement utile lorsque plusieurs solutions raisonnables ont des coûts différents et significatifs. Il apprend à comparer les compromis dans le contexte d’un système précis. Présentation du livre par l’éditeur.

Imaginons que la planification dispose désormais de sa propre équipe et s’intègre à plusieurs partenaires. Un service distinct peut donner à cette équipe davantage de liberté de déploiement. En même temps, un simple appel de méthode devient une opération qui peut prendre du retard, s’exécuter deux fois ou se terminer sans réponse. La règle métier reste valable, mais les conditions nécessaires pour la garantir ont changé.

L’outbox comble une faille précise. Le processus complet demande encore plusieurs décisions.

Si nous enregistrons l’intervention puis envoyons l’événement, le processus peut s’arrêter entre ces deux opérations. L’enregistrement restera en base, mais le message n’arrivera pas. Le modèle transactional outbox enregistre le changement métier et l’intention de publication dans la même transaction locale. Un mécanisme distinct publie ensuite l’événement. Le broker ou le mécanisme de publication peut toujours livrer un doublon : le destinataire doit donc y être préparé. Présentation de l’outbox dans Azure Architecture Center.

Chez le destinataire, l’enregistrement de l’identifiant de l’événement traité et le changement métier doivent former une seule transaction locale, avec une contrainte d’unicité sur le couple destinataire–EventId. Vérifier simplement « l’ai-je déjà vu ? » avant l’écriture ne suffit pas lorsque les messages arrivent en parallèle. Si l’effet attendu est un appel à une API externe, la sécurité des nouvelles tentatives exige une solution distincte, par exemple une clé d’idempotence prise en charge par le fournisseur.

Il nous faut également une politique d’ordonnancement. Un événement en version 8 ne doit pas faire régresser silencieusement une projection qui connaît la version 9. Nous pouvons contrôler les versions et traiter les trous dans la séquence, ou utiliser un mécanisme d’ordonnancement par intervention. Le choix dépend du broker, du mode de traitement et de la portée attendue : un objet ou un ensemble plus large. Imposer un ordre global à tout coûte souvent plus que cela ne rapporte.

Saga et compensation : que pouvons-nous réellement annuler ?

Une fois le stock et la planification séparés, nous n’avons plus une transaction unique pour l’ensemble du processus. Une saga peut coordonner les étapes locales. Si la réservation de l’équipe échoue, nous déclenchons les mesures correctives convenues : libérer la pièce, enregistrer le résultat et informer le service concerné. La compensation peut elle-même échouer ; elle a donc besoin d’un état persistant, de nouvelles tentatives et d’un chemin d’intervention manuelle. Le modèle Saga dans la documentation Microsoft.

Nous ne pouvons pas remonter le temps ni retirer un message déjà lu. Le sens du statut « annulé » doit être défini avec l’entreprise. Si l’état d’une réservation externe est inconnu après un délai d’attente dépassé, nous ne la déclarons pas immédiatement en échec. Nous commençons par déterminer son résultat. L’interface doit afficher honnêtement un état d’attente ou un besoin de vérification, au lieu de promettre que tout est terminé.

05 / SITE RELIABILITY ENGINEERING

L’architecture doit aussi aider la personne qui décrochera le téléphone après une panne.

L’ouvrage dirigé par Betsy Beyer, Chris Jones, Jennifer Petoff et Niall Richard Murphy montre comment relier le développement du produit à la responsabilité de son fonctionnement. Les SLI, les SLO et le budget d’erreur sont un point de départ utile : que mesurons-nous, quel niveau jugeons-nous suffisant et comment réagissons-nous lorsque nous ne le tenons plus ? La version officielle et gratuite du livre.

Pour Service Nord, nous définissons cet objectif à titre d’exemple : sur une fenêtre glissante de 28 jours, au moins 99,5% des demandes d’intervention correctement acceptées reçoivent un résultat correct et durable en moins de 120 secondes. Ce résultat peut être une confirmation ou un refus justifié. Une erreur d’infrastructure renommée « refus » ne devient pas un résultat correct. Nous nous accordons sur la définition avant de commencer à mesurer.

Il s’agit d’un budget en nombre d’opérations, pas en minutes d’indisponibilité. Les nouvelles tentatives d’une même opération ne doivent pas augmenter le dénominateur. Nous devons aussi définir le traitement des opérations acceptées juste avant la fin de la période d’observation, qui n’ont pas encore disposé de leurs 120 secondes complètes pour se terminer. Sans cette définition, deux équipes peuvent calculer de bonne foi des résultats différents. Les SLI et SLO selon Google SRE.

Un point de terminaison de santé au vert ne suffit pas à confirmer cet objectif. Il faut des événements de début et de fin de processus ainsi que des identifiants cohérents. En complément, nous observons l’âge du plus ancien message de l’outbox, le retard du destinataire, le nombre d’états à vérifier et les compensations en échec. Ces signaux doivent aider à trouver la cause, sans remplacer la mesure de l’expérience utilisateur.

Nous associons au budget une réaction convenue à l’avance. Si le rythme des erreurs laisse prévoir un épuisement rapide du budget, l’équipe limite les livraisons risquées, cherche la cause et améliore la fiabilité. Les correctifs d’urgence et les changements de sécurité font l’objet d’une évaluation du risque distincte. La politique concrète appartient au produit et à son équipe ; vous pouvez partir de l’exemple de politique du livre The Site Reliability Workbook.

Que faut-il garder à côté du code ?

• Une carte des responsabilités. Qui pilote l’incident et qui connaît chaque partie du processus.
• Un mode opératoire. Comment retrouver une intervention par son identifiant, reconnaître une nouvelle tentative sans danger et orienter le cas vers une vérification.
• Un plan de restauration. Une sauvegarde de la base, accompagnée d’une procédure de restauration et de réconciliation de l’état des intégrations, déjà mise à l’épreuve. Le seul statut « sauvegarde effectuée » ne constitue pas un test de restauration.
• Des conditions de déploiement. Compatibilité des contrats et des migrations, activation contrôlée et critère mesurable pour arrêter la livraison.
• Les enseignements de l’incident. Ce qui a compliqué le diagnostic, quelle protection a échoué et comment nous vérifierons l’efficacité de la correction.

Revenir à une version précédente de l’application n’annule pas à lui seul les changements de données ni les effets produits dans un système externe. Il faut donc tester le plan de secours sur un scénario qui respecte l’ordre réel des opérations, et pas seulement sur une base de test vide.

ATELIER / DE LA COMPRÉHENSION À LA DÉCISION

Reconstituez le flux. Puis défendez cinq décisions.

Dans le premier exercice, choisissez les étapes dans le bon ordre. Nous supposons une écriture locale de l’intervention avec l’outbox et un destinataire distinct. Les messages peuvent être livrés plusieurs fois. Le résultat de l’exercice reste dans cet onglet du navigateur.

Après cette lecture, choisissez une décision à améliorer dans votre système.

Vous n’avez pas besoin de mettre en place tous les modèles à la fois. Décrivez un processus : ce qu’il accepte, où il enregistre la vérité, comment il réagit à une répétition et comment vous reconnaissez sa fin. Repérez les endroits où la réponse repose encore sur une supposition. Cette feuille de travail produit souvent un meilleur plan d’action qu’une liste de nouvelles technologies.

Ordre de lecture : Fundamentals vous aidera à nommer les exigences et les compromis. Chez Fowler, vous trouverez les modèles adaptés à votre logique. Domain-Driven Refactoring sera utile pour remettre de l’ordre dans le code existant, The Hard Parts pour séparer les services et les données, et SRE pour transformer les promesses en mesures et en pratique quotidienne. Revenez au chapitre pertinent lorsqu’une décision concrète se présente.

Livres et sources pour poursuivre le travail

Ce guide original s’appuie sur les sujets abordés dans les ouvrages cités et dans la documentation. Les liens renvoient aux auteurs, aux éditeurs et aux ressources officielles. Les exercices ne nécessitent pas d’acheter les livres.

1. Fundamentals of Software Architecture, 2nd Edition — Mark Richards, Neal Ford.
2. Patterns of Enterprise Application Architecture — Martin Fowler, avec les coauteurs mentionnés sur la page du livre.
3. Domain-Driven Refactoring — Alessandro Colla, Alberto Acerbis.
4. Software Architecture: The Hard Parts — Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani.
5. Site Reliability Engineering — sous la direction de Betsy Beyer, Chris Jones, Jennifer Petoff et Niall Richard Murphy.

Pour aller plus loin : Saga, Transactional Outbox, Service Level Objectives et Error Budget Policy.