- La thèse est que la plupart des difficultés fondamentales du développement logiciel surviennent non pas à l’intérieur du code, mais à la frontière (boundary) où se rencontrent code et code, système et système
- Frontière = point de rencontre entre des préoccupations, responsabilités et contextes différents
- Presque tous les actes du développement — séparation des fonctions, modularisation, microservices, etc. — consistent à créer des frontières
- Ironie : on crée des frontières pour gérer la complexité, mais la frontière elle-même devient une nouvelle source de complexité
Les frontières qui apparaissent dans le code
- Frontière appelant-appelé : ambiguïté du contrat, comme
null renvoyé vs exception levée
- Frontière d’interface : loi des fuites d’abstraction — la complexité cachée finit toujours par remonter à travers la frontière
- Frontière de dépendance : les API et bibliothèques externes peuvent changer sans préavis
- Frontière de transformation : comme dans le mismatch objet-relationnel, chaque franchissement de frontière peut déformer ou faire perdre de l’information
- Frontière de confiance : frontière entre données validées et données non validées → vulnérabilités de sécurité, comme la réception de webhooks non signés
- Frontière conception-implémentation : accumulation de pertes d’information à chaque étape, des exigences à la conception, puis à l’implémentation et à l’exploitation
Les frontières physiques
- Frontière d’ordre : l’état peut changer entre des points asynchrones, un problème encore plus grave dans les systèmes distribués
- Frontière d’échelle : au-delà d’un seuil critique, on n’observe plus un changement quantitatif mais qualitatif
- Frontière d’environnement : situations du type « chez moi ça marche »
- Frontière d’infrastructure : une fois les services séparés, il devient impossible de garantir l’atomicité
Les frontières entre les personnes
- Frontière organisationnelle : loi de Conway — la structure de l’organisation détermine la structure du système. Lors d’une réorganisation, les frontières du code et celles de l’organisation se désalignent
- Frontière de communication : comme dans le téléphone arabe, l’intention se déforme à chaque transmission d’une exigence, et le savoir tacite n’est parfois pas transmis du tout
- Frontière utilisateur-développeur : une frontière mise en place par le développeur pour la sécurité peut devenir une barrière pénible pour l’utilisateur
Comment maîtriser les frontières
- Reconnaître les frontières cachées : repérer les couplages invisibles dans le code, comme deux services qui partagent la même table de base de données
- Les patterns ne sont pas la réponse : un pattern n’est qu’une « solution efficace dans certaines conditions » ; il ne faut pas l’appliquer aveuglément
- Trois questions à poser face à une frontière :
- Qu’est-ce qui traverse cette frontière ?
- Que se passe-t-il si cette frontière casse ?
- Qui est responsable de la gestion de cette frontière ?
- Ne pas tracer de frontière est aussi un choix : conserver un monolithe, éviter les séparations prématurées, etc.
- Les frontières évoluent : on sépare puis on regroupe, on regroupe puis on redivise → nécessité d’une réévaluation consciente et régulière
Aucun commentaire pour le moment.