The Hard Parts

1Pas de best practices, seulement le moins pire des compromis

Le chapitre d'ouverture pose le pari du livre : si une pratique était vraiment « best », tout le monde l'appliquerait et le problème serait ennuyeux. Les problèmes qui restent sont ceux sans réponse générale : « pour les architectes, chaque problème est un flocon de neige » (ch. 1). La compétence à construire n'est donc pas choisir le bon pattern, c'est peser : « ne cherchez pas le meilleur design ; visez la moins mauvaise combinaison de compromis » (ch. 1).

Deux outils portent cette discipline tout au long du livre. Les ADR (Architecture Decision Records : contexte, décision, conséquences, pour que le « pourquoi » survive aux personnes). Et les fitness functions : des règles d'architecture transformées en tests exécutables dans la CI, qui font échouer le build dès qu'on viole une frontière.

// une règle d'archi devient un test (ici ArchUnit, en Java)
noClasses().that().resideInAPackage("..domaine..")
  .should().dependOnClassesThat().resideInAPackage("..web..");
// le métier qui importe le contrôleur → la CI passe au rouge, pas une revue à attraper

Le livre suit ensuite une équipe fictive, la Sysops Squad, dont le monolithe de tickets vieillissant gèle pendant des heures et menace toute la ligne de business.

2Le quantum d'architecture : votre base partagée vous trahit

L'unité de mesure du livre : un quantum d'architecture est « un artefact déployable indépendamment, à forte cohésion fonctionnelle, fort couplage statique et couplage dynamique synchrone » (ch. 2). Concrètement : le plus petit morceau de votre système que vous pouvez déployer seul. Et le comptage est brutal : un monolithe vaut un quantum, évidemment, mais vingt « microservices » qui partagent une base de données aussi. Si le schéma change et que tout le monde doit bouger ensemble, vous avez un quantum, plus la facture réseau.

Dessous se cache la grille de lecture du livre pour le couplage à l'exécution, trois dimensions à deux valeurs chacune : communication (synchrone ou asynchrone), cohérence (atomique ou éventuelle), coordination (orchestrée ou chorégraphiée). Gardez ça en tête : le 2 × 2 × 2 revient à l'idée 7.

3Découper la base est plus dur que découper le code

« Casser une base de données est difficile : bien plus difficile, en fait, que casser la fonctionnalité applicative » (ch. 6). Le code a des imports qu'on peut lister ; la donnée a des clés étrangères, des vues, des triggers, et ce détail gênant qu'elle est l'actif le plus précieux de l'entreprise. L'argument du livre face à une DBA sceptique est chiffré : un monolithe à 200 connexions de base, redistribué sur 50 services avec leurs pools et leurs instances minimales, en réclame 1 000 à 1 700 pour la même charge.

La méthode tient en cinq étapes qui ne cassent jamais la prod : regrouper les tables en domaines de données, les déplacer dans des schémas séparés, démêler les connexions inter-domaines, puis (et seulement alors) déménager les schémas sur leurs propres serveurs, et basculer. Le slogan du chapitre : la donnée suit les domaines, pas la technologie.

4La granularité est un équilibre, pas un seuil

Quelle taille pour un service ? Le livre refuse la question et la remplace par deux listes opposées. Six raisons de découper (les désintégrateurs) : périmètre mono-fonction, volatilité du code, besoins de montée en charge divergents, isolation des pannes, frontières de sécurité, extensibilité prévue. Quatre raisons de regrouper (les intégrateurs) : transactions de base de données, workflows bavards entre les morceaux, code partagé massif, données étroitement liées.

La démonstration tourne sur un service de notifications : envoyer SMS, emails et courriers papier semble cohérent, jusqu'à apprendre que les modèles de courrier changent chaque semaine quand le code SMS dort six mois (la volatilité dit : découpe), et que le système pousse 220 000 SMS par minute contre une lettre (la scalabilité dit : découpe). Mais cinq services client enchaînés dans un workflow additionnent 1 500 ms de latence réseau pure (le workflow dit : regroupe). « Le secret du bon niveau de granularité, c'est l'équilibre entre ces deux forces opposées » (ch. 7). Test bonus : si le service restant ne peut s'appeler que « Service Divers », le découpage était mauvais.

5La réutilisation, c'est du couplage en costume

La loi la plus citable du livre : « la réutilisation naît de l'abstraction, mais elle ne fonctionne que par la lenteur du changement » (ch. 8). On peut dépendre sans risque d'un OS, d'un framework, de JUnit : des abstractions qui changent lentement et de façon prévisible. Une classe Customer métier interne change à chaque sprint ; partagez-la entre services et chaque changement se propage partout. Cette phrase est l'autopsie du SOA des années 2000 et de son rêve du service Customer d'entreprise réutilisable, que le livre qualifie de désastre architectural.

Quatre options honnêtes sont pesées : copier le code (très bien pour du code qui ne change jamais), la bibliothèque partagée (sécurité à la compilation, douleurs de versioning), le service partagé (bon pour le code volatile, mais un risque d'exécution pour tout le monde), et les sidecars pour la plomberie opérationnelle (logs, monitoring, auth), seul endroit où la réutilisation est inconditionnellement bon marché parce qu'elle ne porte aucune logique métier.

6ACID ne survit pas à la distribution

Le chapitre que toute équipe microservices devrait lire avant le premier incident : dès qu'une transaction métier traverse plusieurs services, chaque lettre d'ACID meurt en silence. Pas de rollback global (chaque service committe sa part), pas d'isolation (les données commitées sont visibles avant la fin de la « transaction »), pas de clés étrangères entre services. À la place, vous obtenez BASE : disponibilité de base, état flou en cours de route, cohérence éventuelle.

Comme il n'y a plus de rollback automatique, c'est à VOUS d'écrire la marche arrière, à la main, étape par étape, ce qu'on appelle une saga :

try {
  paiement.debiter()      // service 1 : commité tout de suite, pas de rollback global
  stock.reserver()        // service 2 : échoue ici…
} catch {
  paiement.rembourser()   // …on doit COMPENSER l'étape 1 à la main (et si ça échoue ?)
}

Trois patterns livrent cet « éventuel » : un batch de fond qui réconcilie (lent, et il piétine tous les bounded contexts, les périmètres métier autonomes), un orchestrateur qui appelle tout le monde pendant que l'utilisateur attend (cohérent, mais la compensation peut elle-même échouer), ou des événements sur un broker durable (réactif et découplé, mais le chemin d'erreur finit en dead letter queue, la file des messages échoués qu'un humain doit traiter). Le clin d'œil récurrent du livre vient du titre culte de Gregor Hohpe : « Starbucks n'utilise pas le two-phase commit ». Vous non plus, donc.

7Les huit sagas : donner un nom à ses ennuis

Croisez les trois dimensions d'exécution (sync/async × atomique/éventuel × orchestré/chorégraphié) et vous obtenez exactement huit sagas transactionnelles possibles. Le livre nomme chacune d'après le genre d'histoire dans laquelle elle vous embarque, et ces noms travaillent vraiment en réunion.

Le diagnostic derrière les couleurs : l'atomicité distribuée est la colonne qui coûte. « Les transactions distribuées présentent une foule de difficultés et il vaut mieux les éviter quand c'est possible » (ch. 12). La Horror Story mérite son nom parce qu'elle est bien intentionnée : un architecte accélère une Epic Saga trop lente avec de l'async et sans coordinateur, tout en gardant l'atomicité, et atterrit sur la pire complexité du tableau.

8Construisez votre propre analyse, et fuyez les évangélistes

Le dernier chapitre replie tout le livre en une méthode réutilisable en trois pas : trouver quelles parties sont enchevêtrées (ce qui change ensemble), analyser comment elles se couplent, puis évaluer en jouant des scénarios « et si » concrets tirés de votre domaine. Avec deux garde-fous : les listes MECE (Mutually Exclusive, Collectively Exhaustive : des options qui ne se chevauchent pas et qui couvrent tous les cas, pour comparer du comparable sans rien oublier) et le piège du hors-contexte (un gagnant générique peut perdre lourdement dès que vos vraies contraintes entrent dans la pièce).

Et une loi qui explique des années de frustration : « un architecte ne peut jamais réduire le couplage sémantique par l'implémentation, mais il peut l'aggraver » (ch. 11). Si le workflow métier est intrinsèquement emmêlé, aucune technologie ne le démêle ; les outils ne peuvent que refléter le domaine ou ajouter de la complexité accidentelle par-dessus. D'où le conseil de clôture : « un architecte apporte de la vraie valeur non pas en chassant balle en argent après balle en argent, mais en affûtant sa capacité à analyser les compromis à mesure qu'ils se présentent » (ch. 15).