Action visiteur
Tu cliques sur le bouton.
Une petite démo de la manière dont ce site est câblé. Un clic traverse l’UI, la frontière API, la persistance, le broadcast temps réel et l’état live, pour rendre les pièces visibles au lieu de seulement les décrire.
Tu cliques sur le bouton.
Le composant appelle un service typé et met à jour l’état UI.
Un endpoint minimal reçoit l’action et valide le flux.
L’événement est sauvegardé pour que le compteur survive aux redémarrages.
Le backend pousse le nouvel état vers tous les navigateurs connectés.
Chaque visiteur voit le système réagir sans rafraîchir.
Le chemin d’exécution te montre où va une requête. L’architecture te montre comment les responsabilités autour de cette requête sont organisées.
La même action applicative peut traverser des structures très différentes selon la façon dont les responsabilités et les dépendances sont organisées. Choisis une architecture et suis la requête.
Ce sont différentes façons de structurer une application, pas un classement.
Scénario : un utilisateur envoie une requête pour réserver un appel.
Déclenche l’action applicative
ex. clique sur « Booking »
Reçoit la requête HTTP
ex. reçoit la requête Booking
Coordonne le comportement métier
ex. valide et traite le Booking
Gère l’accès à la persistance
ex. crée le Booking
Stocke l’état de l’application
ex. création de la ligne Booking
Les responsabilités sont regroupées en couches horizontales, chaque couche gérant une préoccupation technique précise.
L’application est simple et le graphe de dépendances reste facile à suivre.
En grandissant, les couches peuvent se coupler fortement et un même flux métier peut se retrouver dispersé entre plusieurs couches techniques.
Si ta base de code a besoin de frontières plus claires, d’un nouveau flux applicatif, ou d’un travail sur le frontend et le backend, dis-moi sur quoi tu travailles.