Antichesse (o ^ω^ o)
Un site qui répertorie les grands designs d'architectures (pour @animal et @doudou).
Beaucoup de choses appelées patterns ne le sont pas vraiment, on sent le côté buzz-word ou éléments de langage pour apporter de la crédibilité à son discours (surtout à des managers) mais bon, le marché étant ce qu'il est, mieux vaut s'adapter même si l'on n'est pas d'accord.
Je discutais des Monolithes modulaires avec @Chlouchloutte un peu avant les vacances et d'ailleurs j'étais revenue sur l'idée du pur micro-service avec @Kysofer et @Lenny à propos du travail qu'ils font sur leur projet.
Je pense que cet article que me propose @Philou est peu ou prou ce qu'il fallait formaliser, merci à toi.
Je vais faire ma mijaurée mais pas grave.
Quand je lis :
L’architecture applicative apporte une réponse à la question suivante :
Comment les éléments fonctionnels sont ils implémentés ? Le COMMENT ?
Cette architecture représente l’implémentation des services fonctionnels sous forme d’éléments applicatifs.
Elle est composée d’éléments applicatifs (ex : composants Java, .net, objets BDD,…). L’architecture applicative représente le premier niveau d’une projection entre une architecture fonctionnelle (et ses services métiers) et des technologies qui vont devoir supporter ces services. Elle est une instanciation de l’architecture fonctionnelle.
et ceci :
L’architecture technique apporte une réponse la question suivante :
Avec quels éléments techniques, les éléments applicatifs sont ils déployés ? Le AVEC QUOI ?
Cette architecture décrit l’infrastructure sur laquelle les éléments applicatifs ont été déployés.
Elle est décomposée en deux couches :
Une couche de logiciels médiateurs (ou middleware) qui est composée des progiciels : moteurs des bases de données, serveur d’application, serveur web, annuaire LDAP, ordonnanceur, gestionnaires de flux (EAI, ESB, ETL, …), etc.
Une couche matérielle qui est composée des logiciels de base (systèmes d’exploitation), des serveurs et des réseaux.
Mon petit cerveau de lémurienne fait tilt ! Sur quel critères rationnels, objectifs et argumentés LDAP serait plus du côté de l"architecture technique que du côté de l'architecture applicative ? Même question mais dans l'autre sens pour Java ? Quid des "objets BDD", de l'ordonnanceur, du gestionnaire de flux, ie. un BPM ? Un F5 ? Un load-balancer ?
Bref, la réalité est simple : l'architecture applicative et l'architecture technique constituent le même objet, elle sont la même chose ! Et le choix d'architecture doit être uniquement pris par les équipes produits constituées de développeurs.
Car oui, l'architecture, c'est du code point. Un design orienté micro-service, c'est du code. Le choix de frameworks, c'est du code qui impact du code. Les flux de données, c'est du code sous contrainte.
Les architectes sont dans un délire pluri-décennal consistant à croire que c'est leur compréhension qui part en production, or c'est archi-faux ! Leur position est d'être celle du dirigeant, du leader alors qu'elle devrait se contenir à celle d'un documentaliste ou d'un bibliothécaire #CommentCaCoupBas.
Moins d'architecte & Plus de développeurs => meilleurs logiciels de meilleurs qualité.
Quant à tout ceux qui pensent le contraire, les logiciels les moins fiables sur terre ont des équipes bardées d'architectes (coucou Microchiotte) tandis que ceux qui sont les plus fiables n'ont quasiment que des développeurs (coucou Linux, les logiciels libres & stuff).
Aussi, c'est certes un sophisme que de conclure + d'architectes => + de problèmes car corrélation n'implique pas une causalité, mais ce sera quand même ma conclusion car je n'ai aucun contre-exemple depuis 15 années passées sur le terrain !
An attempt at modelling digital design as a form of psychological architecture, taking the form of a single HTML document.
Que du bon sens sur ce pourquoi et comment un site web est utilisé.
A lot of programmers make the mistake of thinking the way you make code flexible is by predicting as many future uses as possible, but this paradoxically leads to less flexible code. The only way to achieve flexibility is to make things as simple and easy to change as you can.
A random guy on Twitter
@Chlouchloutte m'a faite découvrir ce diagramme il y a quelques minutes.
J'avoue que je ne sais pas trop quoi en penser dans le sens où il m'apparaît comme très procédurale. Typiquement en OOP (Object Oriented Programming), nous avons une encapsulation des données et les traitements qui s'appliqueront sur elles au sein d'une même classe. Or, le découpage en couche implique une séparation des données dans des structures et l'application d'une logique applicative, répartie en couche. Les structures / entités traversant toutes les couches.
Ce n'est pas objet pour un sou. Et ce sera même quasiment impossible de coder proprement en objet avec de telles architectures puisque chaque couche insistera pour séparer les entités des traitements. De facto, nous nous retrouverons avec une armada de développeurs arguant que l'objet "sainul" puisqu'ils ne pourront tout simplement jamais exprimer facilement en objet. Ainsi, les classes issues de l'OOP se résumeront à être de simple modules (au sens Functional-Programming du terme, c'est-à-dire un namespace de fonctions) et les instances ne seront plus que des singletons, qu'ils soient gérés manuellement ou via Spring.
Pour faire de l'objet, il faut que votre architecture soit orientée objet (je simplifie). Pour coder en fonctionnel, il faut que vos données soit accessibles dans des monades (je simplifie aussi). Pour tirer le meilleur des deux mondes, il vous suffit d'avoir une architecture orientée objet, des algorithmes codés via une approche fonctionnelle. Mais visiblement, mes contemporains préfèrent une lutte de religion radicale que de découvrir les avantages de l'autre camp.
@Chlouchloutte j'aurai quand même besoin de te reposer des questions.
Architecture Decision Record
Autre temps autre méthode. En résumé, quelles sont les bonnes pratiques de documentation dans un cadre agile.
Je résume : en quoi les micro-services sont peut-être de la brave merde. Autrement dit, une architecture micro-service est-elle nécessaire à tous et s'applique-t-elle pour tous ?
Fabriquer un micro-service à partir d'un Jetty embarqué et sélectionner les modules de Jetty pour que son micro-service soit modulaire.
Enjoy :D
Un article à lire pour Roudoudoutte.
Vous démarrez un projet, vous vous posez le choix de la techno, des outils de build, le dependencies manager, la software factory, software quality, le framework architectural, ce projet GitHub constitue une documentation complète sur l'ensemble des outils existant pour les 20 principaux langages (à cette heure, sûrement plus au fil du temps). Idéal pour savoir quoi prendre au lieu de démarrer sur les chapeau de roues.
Les quatre règles à suivre pour améliorer le design de son application.