5. Concevoir un système que l'on peut faire évoluer
L'architecture est la manière dont un système est découpé et relié. Ce mot ne désigne pas un schéma décoratif : il désigne les choix qui rendent certains changements simples et d'autres coûteux.
Des frontières qui ont du sens
Une frontière sépare des responsabilités. Un composant chargé du paiement ne devrait pas avoir à connaître chaque détail de l'affichage d'un catalogue. Cette séparation rend l'ensemble plus facile à comprendre, à tester et à modifier.
Mais séparer n'est pas automatiquement simplifier. Multiplier les services, les bases de données ou les messages peut aussi créer des chemins plus difficiles à suivre. Une bonne frontière réduit une coordination inutile tout en laissant les personnes capables de résoudre les problèmes ensemble quand elles le doivent.
Les dépendances sont normales ; les dépendances cachées sont coûteuses
Un système dépend souvent d'un fournisseur de paiement, d'un outil d'email ou d'un autre service interne. La question n'est pas « comment supprimer toute dépendance ? » ; elle est « que se passe-t-il quand cette dépendance est lente, indisponible ou change ? ».
Les réponses possibles incluent un délai maximal d'attente, une réponse dégradée mais honnête, une file pour reprendre plus tard ou une information claire à l'utilisateur. Ce sont des choix de produit autant que des choix techniques.
La simplicité est contextuelle
Une petite application n'a pas besoin de la même structure qu'une plateforme critique. Ajouter une abstraction sans problème réel peut obscurcir le système. À l'inverse, conserver une zone confuse parce qu'elle fonctionne encore peut rendre chaque changement futur plus risqué. L'équipe cherche une simplicité utile : assez de structure pour changer sans peur, pas plus de mécanismes que le besoin ne le justifie.
Pour aller plus loin : frontières et cohésion, couplage et dépendances et architecture évolutive.