Architecture logicielle & bonnes pratiques

Concevoir des applications évolutives et maintenir un code propre

Le code fonctionne. C'est le modifier qui coûte cher.

Un projet démarre toujours vite. Six mois plus tard, ajouter un champ dans un formulaire prend trois jours au lieu de trois heures, et plus personne n'ouvre la fonction de 400 lignes. La dette technique n'est pas une faute morale, c'est un coût qui se cumule à chaque modification.

L'excès inverse coûte autant, et il est moins souvent nommé. Six couches d'abstraction posées sur un besoin qui n'en demandait aucune, une interface par classe, un événement là où un appel suffisait : le résultat se modifie aussi mal que le code qu'on voulait éviter.

À quoi sert ce livre. Apprendre à trancher entre les deux. Pas à réciter des principes, mais à juger, pour un problème donné, combien de structure il mérite réellement, et à défendre ce jugement devant une équipe.

Ce que vous saurez faire après lecture

• Dériver un état plutôt que le stocker, et reconnaître le cas où le cache devient nécessaire
• Nommer laquelle des cinq lettres de SOLID une classe viole, et la corriger sans casser ses appelants
• Isoler un domaine métier derrière des ports et des adaptateurs, et le tester sans base de données
• Faire évoluer une API sans rompre le contrat de ses clients
• Écrire un test de caractérisation avant de refactorer du code que personne ne comprend plus
• Choisir entre Repository, Factory, Strategy, Observer et injection de dépendances selon le problème réellement présent
• Situer un test dans la pyramide et savoir où le mocking devient un mensonge
• Corréler des logs par requête et poser un circuit breaker qui protège vraiment
• Arbitrer entre monolithe modulaire et microservices sur un critère mesurable
• Écrire un ADR encore lisible dix-huit mois plus tard

La méthode. Chaque notion arrive par un « avant » commenté et un « après », en Java avec Spring. Puis un cas limite montre où la règle cesse de s'appliquer : le port qui fuit un détail d'infrastructure, le test de caractérisation qui documente un bug, le circuit breaker contourné par une auto-invocation. Un tableau ferme chaque chapitre sur les pièges de sur-ingénierie associés à ce qui vient d'être appris.

Six questions corrigées par chapitre, avec une justification écrite pour chaque réponse. De quoi vérifier qu'une notion est acquise avant de passer à la suivante.

Pour qui

Un développeur de niveau intermédiaire à confirmé, qui écrit du code qui marche et bute sur celui qu'il faut rouvrir six mois plus tard. Les exemples sont en Java avec Spring ; les principes se transposent à toute pile serveur. Le livre ne traite ni le dimensionnement d'infrastructure, ni les campagnes de tests de charge.

Ce que contient le livre

• 12 chapitres répartis sur 192 pages, soit environ 38 489 mots.
• 16 diagrammes pour les schémas d’architecture et les flux.
• Trois formats livrés : PDF pour la lecture à l’écran, EPUB et Kindle pour la liseuse.