Le livre «Architecture évolutive. Soutien au changement continu "

Il est temps de revoir les postulats qui sont restés inchangés au fil des ans. Un monde en évolution dynamique dicte ses propres règles, y compris dans l'architecture informatique. Les changements en cours nécessitent de nouvelles approches, obligeant les systèmes rigides à devenir flexibles et à s'adapter aux nouvelles conditions. Une planification à long terme est-elle possible si tout change constamment? Comment éviter la dégradation progressive de la solution architecturale dans le temps? Vous trouverez ici des réponses et des recommandations qui protégeront les caractéristiques les plus importantes du projet dans le contexte de changements continus. «Ce livre marque une étape importante dans la compréhension actuelle du problème. Au fur et à mesure que les gens prennent conscience du rôle des logiciels au 21e siècle, l'information sur la façon de réagir au changement tout en maintenant ce qui a été réalisé devient une compétence essentielle dans le développement de logiciels. » - Martin Fowler

Architecture évolutive: pièges et antipatterns

Nous avons passé beaucoup de temps à discuter des niveaux appropriés de connectivité en architecture. Cependant, nous vivons également dans le monde réel et observons de nombreuses interconnexions qui nuisent à la capacité d'évolution du projet.

Deux mauvaises pratiques de conception ont été identifiées qui se manifestent dans les projets logiciels: les pièges et les antipatterns. De nombreux développeurs utilisent le mot antipatterns comme terme d'argot «mauvais», mais sa véritable signification doit être clarifiée. Le logiciel Antipattern se compose de deux parties. Première partie: l'antipattern est une pratique qui semble au départ une bonne idée, mais qui se transforme en erreur. Deuxième partie: pour la plupart des antipatterns, il existe de nombreuses alternatives bien meilleures. Les développeurs d'architecture ne remarquent beaucoup d'antipatterns que rétrospectivement, il est donc difficile de les éviter. Le piège à première vue semble être une bonne idée, mais se manifeste immédiatement comme une mauvaise façon. Dans ce chapitre, nous examinons ensemble les pièges et les contre-modèles.

Architecture technique

Cette section se concentre sur les pratiques courantes utilisées dans l'industrie, ce qui est particulièrement préjudiciable à la capacité de l'équipe à faire évoluer l'architecture.

Antipattern: Roi vendeur

Certaines grandes entreprises achètent un logiciel ERP (Enterprise Resource Planning) pour résoudre les tâches commerciales courantes, telles que la comptabilité, la gestion des stocks et d'autres opérations de routine. Cela fonctionne si les entreprises sont prêtes à plier leurs processus commerciaux et d'autres solutions afin d'adapter cet outil, et peut être utilisé de manière stratégique lorsque les développeurs d'architecture comprennent les limites et les avantages.

Cependant, de nombreuses organisations deviennent trop ambitieuses en ce qui concerne les logiciels de cette catégorie, ce qui conduit à l'anti-modèle du roi du fournisseur, dont l'architecture est entièrement basée sur les produits du fournisseur, ce qui lie pathologiquement l'organisation à cet outil. Les sociétés achetant des logiciels fournisseurs prévoient d'augmenter le package avec ses plug-ins afin d'étendre les fonctionnalités de base pour les aligner sur le domaine d'activité de l'entreprise. Cependant, pendant longtemps, l'outil ERP ne peut pas être configuré suffisamment pour implémenter pleinement ce qui est nécessaire, et les développeurs se retrouvent impuissants en raison des limites de l'outil et parce qu'ils en ont fait le centre de l'univers architectural. En d'autres termes, les développeurs d'architecture ont fait le fournisseur du roi de leur architecture, dictant les décisions futures.

Afin d'éviter les contre-modèles, il faut considérer le logiciel simplement comme un autre point d'intégration, même s'il avait initialement un large éventail de responsabilités. En supposant l'intégration au stade initial, il est plus facile de changer des caractéristiques inutiles avec d'autres points d'intégration, renversant le roi du trône.

En plaçant un outil ou une plateforme externe au cœur même de l'architecture, les développeurs ont considérablement limité leur capacité à évoluer dans deux directions principales, à savoir, techniquement et du point de vue du processus métier. Les développeurs sont techniquement limités par le choix du fournisseur en ce qui concerne les systèmes de stockage, l'infrastructure prise en charge et de nombreuses autres restrictions. Du point de vue du sujet, un grand outil d'encapsulation souffre finalement de l'anti-motif «Piège sur les 10 derniers%». Du point de vue des processus métier, cet outil ne peut pas prendre en charge un flux de travail optimal; c'est un effet secondaire ou un piège dans les 10 derniers%. La plupart des entreprises ferment leurs portes en se soumettant à la plateforme, en remplaçant les processus, plutôt qu'en essayant de personnaliser l'outil. Plus les entreprises le font, moins il y a de caractéristiques distinctives entre les entreprises, ce qui est formidable car la différence n'est pas un avantage.

Le principe arrêtons le travail et appelons-le succès est l'un de ceux que les développeurs considèrent généralement lorsqu'ils traitent avec des packages ERP dans le monde réel. Puisqu'elles nécessitent des investissements importants en temps et en argent, les entreprises hésitent à les accepter lorsqu'elles ne travaillent pas. Aucun service technique ne veut accepter la perte de millions de dollars, et le fournisseur de l'outil ne veut pas accepter une mauvaise implémentation multicouche. Ainsi, chacune des parties s'engage à arrêter le travail et à le qualifier de succès avec la plupart des fonctionnalités promises non réalisées.

N'associez pas votre architecture au roi fournisseur.

Au lieu de devenir la proie de l'anti-modèle du roi des fournisseurs, envisagez de considérer les produits des fournisseurs comme un autre point d'intégration. Les développements peuvent isoler les changements de l'outil du fournisseur de l'impact de leur architecture en créant des couches de résistance à la destruction entre les points d'intégration.

Piège: abstraction trouée

Toutes les abstractions non triviales sont dans une certaine mesure pleines de trous.
- Joel Spolsky

Les logiciels modernes reposent sur une tour d'abstractions: systèmes d'exploitation, plates-formes, dépendances, etc. En tant que développeurs, nous construisons des abstractions de telle manière que nous n'avons pas la capacité de penser en permanence aux niveaux inférieurs. Si les développeurs avaient besoin de traduire les nombres binaires provenant des disques durs dans le texte du programme, ils ne pourront jamais rien faire! L'un des triomphes des logiciels modernes est notre capacité à construire des abstractions efficaces.

Mais les abstractions coûtent cher, car il n'y a pas d'abstractions parfaites, et si elles l'étaient, elles ne seraient pas des abstractions, mais quelque chose de réel. Selon Joel Spolsky, toutes les abstractions non triviales ont un trou (fuite). C'est un problème pour les développeurs car nous pensons que les abstractions sont toujours précises, mais elles s'effondrent souvent à merveille.

La complexité accrue des piles technologiques a récemment transformé l'abstraction en un problème dévastateur. Dans la fig. 7.1 présente une pile technologique typique datant d'environ 2005.

Dans cette pile, le nom du fournisseur sur les blocs change en fonction des conditions locales. Au fil du temps, à mesure que les logiciels deviennent plus spécialisés, notre pile technologique devient plus complexe, comme le montre la figure 2. 7.2.


Comme on peut le voir sur la fig. 7.2, chaque partie de l'écosystème logiciel s'est développée et est devenue plus complexe. Comme les problèmes auxquels les développeurs sont confrontés deviennent de plus en plus complexes, leurs solutions le sont également.

L'abstraction trouée initiale , où l'abstraction destructrice à un faible niveau conduit à un chaos inattendu, est l'un des effets secondaires de l'augmentation de la complexité de la pile technologique. Que se passe-t-il si l'une des abstractions au niveau le plus bas échoue, par exemple, un effet secondaire inattendu d'un appel de base de données apparemment inoffensif? Puisqu'il y a tellement de couches, cet échec se déplacera vers le haut de cette pile, provoquant probablement des «métastases» sur son chemin, se manifestant par un message d'erreur profondément intégré dans l'interface utilisateur. Le débogage et l'analyse rétrospective deviennent plus difficiles à mesure que la pile technologique est complexe.

Essayez de bien comprendre au moins un niveau d'abstraction en dessous du niveau auquel vous travaillez habituellement.
- Logiciel Sages

Bien que la compréhension de la couche ci-dessous soit un bon conseil, elle devient de plus en plus difficile à suivre car le logiciel se spécialise et devient plus complexe.

L'augmentation de la complexité de la pile technologique est un exemple de problème d'équilibre dynamique. Non seulement l'écosystème change, mais ses éléments constitutifs deviennent plus complexes et confus au fil du temps. Le mécanisme proposé pour protéger les changements en évolution, à savoir l'utilisation des fonctions de fitness, peut protéger les points fragiles des connexions d'architecture. Les architectes définissent des invariants aux points d'intégration clés, tels que les fonctions d'adéquation, qui fonctionnent dans le cadre du pipeline de déploiement, garantissant que l'abstraction ne commence pas à circuler de manière indésirable.

»Plus d'informations sur le livre sont disponibles sur le site Web de l'éditeur

Pour habrozhitelami 20% de réduction sur le coupon - Architecture évolutive