Avec cela, je devrais être en mesure de me débarrasser de tout ce qui touche à de l'introspection et donc me rapprocher de la compilation native :D (avec ce maudit Spring Boot que j'ai appris à détester avec le temps).
L'exemple donné
package com.zetcode.routes;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.reactive.function.server.RouterFunction;
import org.springframework.web.reactive.function.server.ServerResponse;
import static org.springframework.web.reactive.function.BodyInserters.fromValue;
import static org.springframework.web.reactive.function.server.RequestPredicates.GET;
import static org.springframework.web.reactive.function.server.RouterFunctions.route;
import static org.springframework.web.reactive.function.server.ServerResponse.ok;
@Configuration
public class MyRoutes {
@Bean
RouterFunction<ServerResponse> home() {
return route(GET("/"), request -> ok().body(fromValue("Home page")));
}
@Bean
RouterFunction<ServerResponse> about() {
return route(GET("/about"), request -> ok().body(fromValue("About page")));
}
}
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 !
Un très bon article qui compare les systèmes de preuve formelle vs les TU et les langages fonctionnels et orientés objets.